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

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

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

On Wed, 22 Apr 2009, dave at hiauly1 dot hia dot nrc dot ca wrote:

> >  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.
> 
> My concern is that this may remove the `l' ending math functions
> completely and their declarations.  Unless the ABI is bumped, this
> may break existing code.  It not at all clear to me that this is
> compatible with C99.

Correct, removing these declarations (as glibc does on these platforms - I 
think SH is the only one affected not in ports) is not conforming to C99, 
whereas having the types the same width (but distinct types at the C 
language level) with the declarations present does conform.  This is on my 
list of C standards issues in glibc, but I think it (and some other 
issues) may be deliberate on the part of the glibc maintainers.

glibc does provide the functions on affected platforms, it just doesn't 
provide the required header declarations of them in math.h and complex.h.


-- 


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