From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30072 invoked by alias); 29 Apr 2009 15:07:56 -0000 Received: (qmail 28846 invoked by uid 48); 29 Apr 2009 15:07:29 -0000 Date: Wed, 29 Apr 2009 15:07:00 -0000 Message-ID: <20090429150729.28844.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/39491] [4.2/4.3 regression] symbol __signbitl@GLIBCXX_3.4 in libstdc++ exported In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "carlos at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-04/txt/msg02911.txt.bz2 ------- 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