[Patches] Trunk merge 2011-10-24

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

I've done a merge from FSF to EGLIBC trunk.

This brings in the libm changes to add __*_finite entry points to various 
functions for -ffinite-math-only.  I looked at how this would interact 
with the change in EGLIBC to ensure that long double functions are 
properly declared even when long double has the same ABI as double (a 
patch Jakub originally sent to libc-hacker but that never got into FSF 
glibc).

There are two types of targets with such issues:

(a) Targets with multiple long double ABIs, building with -mlong-double-64 
(for example, powerpc-linux-gnu).

(b) Targets with no ABI where long double is wider than double (for 
example, arm-linux-gnueabi).

For targets of type (a), where there is no difference between FSF glibc 
and EGLIBC, the functions in libc with "l" suffixes (with and without 
_finite) are the versions for 128-bit long double, and the headers arrange 
for -mlong-double-64 to map calls to long double functions to the 
corresponding double functions via "asm" declarations.  The mappings for 
-ffinite-math-only come after those ABI-compatibility mappings, and GCC 
will ignore a second asm declaration that conflicts with a first (with a 
warning, but warnings are generally suppressed in system headers).  So the 
effect will be that calling the long double functions with 
-mlong-double-64 doesn't get the optimizations - but they don't get 
wrongly mapped to *l_finite either.

For targets of type (b), in EGLIBC they will behave the same as type (a).  
In FSF glibc the functions will not be declared at all.  In either case, 
the *l_finite functions will not actually exist (meaning that if such a 
target gains a wider long double in future, care will be needed to ensure 
the functions are added at an appropriate symbol version rather than 
GLIBC_2.15).

Thus I believe the present code is safe, although it does rely on the 
first renaming of a function with an "asm" declaration taking precedence 
over any subsequent renaming.

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches