This is the mail archive of the
newlib@sources.redhat.com
mailing list for the newlib project.
Re: illegal alias attribute vs ia64 asm_output_labelref
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: illegal alias attribute vs ia64 asm_output_labelref
- From: "J. Johnston" <jjohnstn at cygnus dot com>
- Date: Mon, 20 Aug 2001 19:14:32 -0400
- CC: gcc-patches at gcc dot gnu dot org, newlib at sources dot redhat dot com, cygwin-developers at sources dot redhat dot com
- Organization: Red Hat Inc.
- References: <20010818235115.A22180@redhat.com>
- Reply-To: newlib at sources dot redhat dot com
Richard Henderson wrote:
>
> http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00349.html
>
> This patch broke handling @ and * at the same time in the ia64
> ASM_OUTPUT_LABELREF, which meant that some c++ variables would
> get mangled during output to contain a leading * character.
>
> I wish I'd looked at the reason for this patch when it went in.
> On the face of it it makes no sense -- we're being called to
> emit a label, not an expression. How could there possibly be
> a plus sign embedded?
>
> The answer is this little gem from newlib:
>
> extern _CONST char _ctype_[1 + 256] __attribute__ ((alias ("_ctype_b+127")));
>
> This is illegal code. The argument to the alias attribute is
> a symbol name, not an expression. That it happens to work for
> some targets is immaterial. And before you ask, no, there is
> no way to do what you want. Your best bet is to either push
> ALLOW_NEGATIVE_CTYPE_INDEX into ctype.h and adjust the expressions
> therein or use __ctype_ptr and ignore _ctype_ entirely.
>
> r~
>
My preference has always been to switch to a ctype pointer. The code above
was done to prevent the ctype.h header file from changing due to back-level
compatiblity concerns with Cygwin users.
Both of your proposed solutions require changing ctype.h and breaking Cygwin
back-level compatibility. This being the case, it makes sense to switch to the
pointer mechanism which has potential benefits for locale support.
Cygwin maintainers: any alternative we haven't thought of or can I make the
change?
-- Jeff J.