[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signbitl@GLIBCXX_3.4 in libstdc++ not exported anymore

["carlos at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #18 from carlos at codesourcery dot com  2009-04-22 22:42 -------
Subject: Re:  [4.4/4.5 regression] symbol __signbitl@GLIBCXX_3.4
 in libstdc++ not exported anymore

>> * Original submitter is incorrect, there has never been a
>> __signbitl@GLIBCXX_3.4 symbol, and there should not be one now?
> 
> The symbol is present in libstdc++.so.6.0.9 and libstdc++.so.6.0.10,
> but not in libstdc++.so.6.0.8 or libstdc++.so.6.0.11.

If that's the case, then libstdc++ is to blame, and Benjamin's
hackish patch should be reviewed and checked in.

>> * I have changed the glibc hppa-linux-gnu port to define __NO_LONG_DOUBLE_MATH,
>> and therefore the signbit macro, even in the abscense of optimization, will
>> always return a valid signbit function based on the type size.
> 
> I'm not convinced this is a good idea at this point.  As far as I know,
> it is ok to have the same size for double and long double.  However,
> they are distinct types.

Perhaps I wasn't as clear as I should have been. The glibc port for
hppa has always been configured never to build any long double code,
and has always assumed that long double is not a distinct type.
 From glibc's perspective there is no such thing as having double
and long double with the same size, there is only a configuration
where double exists and all the long double functions alias to their
double equivalents. The hppa port sets long-double-fcts = no in glibc
and this causes all the aliases to be created, otherwise you'd never
be able to link anything that used `l' ending math functions. Defining
__NO_LONG_DOUBLE_MATH is just another step in the right direction to
avoid using long double functions, and use the double functions instead.

The upside is that, if and when, long double on hppa becomes the 128-bit
quad long double, we can just follow the tried-and-tested procedure to
migrate the glibc math routines.

Cheers,
Carlos.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491