[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #11 from carlos at codesourcery dot com 2009-04-21 20:16 --- Yes, if gcc does not determine that "sizeof (x) == sizeof (double)" then it would have to emit code for the if-then-else statement and this would create a reference to an undefined __signbitl. Has this ever happened? I've never seen it. At present glibc does not create an long double alias for the double __signbit function, but for the sake of correctness it probably should. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #16 from carlos at codesourcery dot com 2009-04-22 18:33 --- So what is required to close this issue? * Original submitter is incorrect, there has never been a __signb...@glibcxx_3.4 symbol, and there should not be one now? * glibc on hppa-linux-gnu has never had a __signbitl symbol. * 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #18 from carlos at codesourcery dot com 2009-04-22 22:42 --- Subject: Re: [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore >> * Original submitter is incorrect, there has never been a >> __signb...@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 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #25 from carlos at codesourcery dot com 2009-04-24 20:31 --- Jakub's patch works for me on HPPA, and correctly exports the *l prototypes with __NO_LONG_DOUBLE_MATH set. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.4/4.5 regression] symbol __signb...@glibcxx_3.4 in libstdc++ not exported anymore
--- Comment #26 from carlos at codesourcery dot com 2009-04-24 20:41 --- Action items left: 1) Checkin a patch to libc-ports to define __signbitl as an alias of __signbit on hppa. * Done: http://sourceware.org/ml/glibc-cvs/2009-q2/msg00277.html 2) Someone please add a stub to libstdc++ for __signb...@glibcxx_3.4 that calls __signbitl in glibc. 3) Wait for Jakub to get his patch into glibc core. 4) Enable __NO_LONG_DOUBLE_MATH for hppa (different from NO_LONG_DOUBLE and long-double-fcts = no). #1, #3, and #4 are things I can work on. Can someone please do #2? When #1 and #2 are done we can consider *this* issue closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported
--- Comment #28 from carlos at codesourcery dot com 2009-04-28 20:57 --- Exporting a non-default versioned symbol is useless since new programs won't be able to link against that definition. Did 4.2/4.3 export a global default symbol for __signbitl? If we did export a global default symbol for __signbitl then we must continue to export it. The current glibc math.h signbit macro will evaluate to __signbitl if passed a long dobule type, and therefore correct programs using the signbit macro may have ended up referencing __signbitl from libstdc++. Please comment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
[Bug libstdc++/39491] [4.2/4.3 regression] symbol __signb...@glibcxx_3.4 in libstdc++ exported
--- Comment #32 from carlos at codesourcery dot com 2009-04-29 15:07 --- No, you are absolutely right and the tree dumps confirm it. I thought it might be possible to trigger a reference by using the right flags, but to no avail, the compiler always folds the if-then-else to __signbit. This proves to me that no program could have ever created a reference to __signbitl unless they specifically called __signbitl, which is a but in the application. I now agree with Benjamin that this is a [4.2/4.3 regression]. Notes: * I am using -fno-builtins to avoid the compiler builtins from being used for signbit[fl]. * I would never want libstdc++ to ever provide a default symbol for __signbitl, only a compat one, but this is now moot since we proved no program could ever reference __signbitl. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
