From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1843 invoked by alias); 15 Nov 2011 22:33:55 -0000 Received: (qmail 1831 invoked by uid 22791); 15 Nov 2011 22:33:54 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Nov 2011 22:33:07 +0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/51146] The name clog for a global variable triggers a segfault inside std::pow Date: Tue, 15 Nov 2011 22:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: joseph at codesourcery dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2011-11/txt/msg01577.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51146 --- Comment #6 from joseph at codesourcery dot com 2011-11-15 22:28:38 UTC --- I think this is really a duplicate of an issue discussed in various places before: libstdc++ relies on C library symbols that are not necessarily reserved by the selected version of standard C++, and in particular it relies on them in inline code in headers. This means (a) g++ predefines _GNU_SOURCE, causing headers included by the user to make visible symbols the user didn't want and (b) the use of symbols in the headers conflicts with any symbols of the same name defined by the user. Fixing this would be pretty involved and require close cooperation with libc to provide implementation-namespace versions of every such symbol the library needs, as I said in bug 36231; a lot of work to get this exactly in accordance with the various standards.