This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alpha vs complex functions


> GCC 3.4 fixed an ABI conformance problem with complex values, which
> means that all functions that take single-precision complex parameters
> are incompatible with previous versions of GCC.
> 
> I'm trying to figure out what I want to do about this in glibc.
> 
> I was thinking that one possibility for letting gcc 3.3 and 3.4
> live together on the same machine would be to do stuff like
> 
> #if __GNUC_PREREQ(3, 4)
> float cabsf (_Complex float) __asm__("__c2_cabsf");
> #endif

It seems to me we should invert the sense of hackery.  That is, make the
names straightforward in 3.4 and the future, and wonky for the
compatibility case.  That way, as the legacy bits wither away, the bits
remaining don't have gratuitous cruft like nonobvious names.

So, that says that the references produced by 3.4-compiled code should have
names like `cabsf' (that bind to a new symbol version), while referenced
produced by 3.3-compiled code should refer specifically to the
compatibility symbols.  It might be possible to do this just with:

#if !__GNUC_PREREQ(3,4)
__asm__ (".symver cabsf,cabsf@GLIBC_2.1");
#endif

alongside the decls.  Some experimentation would be required to figure out
if that really avoids any other headaches (e.g., does it produced
gratuitous undefined refs in modules that include the header but don't use
the symbols?).  It would be peachiest if past GCC versions had supported
something like `__attribute__ ((__version__ ("GLIBC_2.1")))', but adding
that now (a good idea IMHO) doesn't help existing compiler versions.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]