From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17320 invoked by alias); 15 Jun 2012 15:38:01 -0000 Received: (qmail 17304 invoked by uid 22791); 15 Jun 2012 15:38:00 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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; Fri, 15 Jun 2012 15:37:48 +0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems Date: Fri, 15 Jun 2012 15:38: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: enhancement X-Bugzilla-Who: redi at gcc dot gnu.org 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: 2012-06/txt/msg01029.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #5 from Jonathan Wakely 2012-06-15 15:37:34 UTC --- (In reply to comment #3) > (In reply to comment #1) > > There's no point differentiating the gnu variants, they don't have any ABI > > impact. > > They don't have any ABI impact that we know of at the present time in this > present generation of GCCs. As a debug aid that's likely to be there from now > on and forever, who's to say about the future. The GCC maintainers are to say. > Better to cover all bases now > I'd say, just in case. There's no point adding (and maintaining) yet another feature to handle hypothetical differences which *by*design* should not happen. Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme doesn't cover. > > This could (and probably should) be done in the library because the output of > > G++ is ABI compatible, it's only standard library components that are not. > > There are no shortage of third party libraries which enable special new stuff > when compiled with GNU additions turned on. Not GCC's problem, and no different to libraries which enable new things when -fno-rtti or -fno-exceptions is used > Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11 > compiled code is not guaranteed in the case where C++11 libraries/shared > objects are linked into a C++03 compiled program. Indeed, really an error ought > to be thrown if this happens for safety's sake, a warning as a minimum. [citation needed] ;) The standard says nothing about "libraries/shared objects" It's entirely possible to use G++ to build 100% ABI compatible applications using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the parts of the standard library that are incompatible. A mandatory or warning would cause problems for anyone doing that.