From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6977 invoked by alias); 15 Jun 2012 16:53:40 -0000 Received: (qmail 6817 invoked by uid 22791); 15 Jun 2012 16:53:39 -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 16:53:26 +0000 From: "s_gccbugzilla at nedprod dot com" 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 16:53: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: s_gccbugzilla at nedprod 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: 2012-06/txt/msg01036.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673 --- Comment #6 from Niall Douglas 2012-06-15 16:53:01 UTC --- (In reply to comment #5) > > 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. It's safer to fail safe. And no maintainer is omniscient. > > 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. There's the ideal world and there's the real world. This is a very likely ongoing real world problem whose fix requires perhaps five lines of new code - hardly a big new feature requiring umpteen lines of code. I'd write the patch myself except I'd put those five lines in the wrong place because GCC's code base is so monolithic. Technically, you could add it to the top of or whatever is a guaranteed included library header: #if defined(__cpluscplus) and __cplusplus==201103L extern "C" void __gplusplus_std_cplusplus11() __attribute__ ((weak)); #elif defined(__cpluscplus) and __cplusplus==199711L extern "C" void __gplusplus_std_cplusplus97() __attribute__ ((weak)); #elif ... #else #error Unknown C++ variant, cannot set magic symbol #endif ... assuming that compiles which I can't test on this laptop. > Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme > doesn't cover. ABI is a GCC issue :). I'd certainly recommend it for that too. You may need to bump ABI if needed to solve C++11 and C++03 interop and a way for checking for that would also be useful. > > 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 Look, it's a debug aid, and if GCC offers special extra features then it's GCC's problem if libraries use them. In the future GCC is going to see lots of C++11 "bugs" submitted. You're going to ask the question "are you *really* sure you compiled everything with C++11?". Right now they'll say yes, but they may well be wrong. This debug aid is as much for your future sanity as anything. > > 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] ;) :) ... I don't suppose you'd take my word as ISO SC22 convenor for Ireland would you? ;) No, it's fair enough, I only know that from watching the discussions on ISO and I have no idea if it's actually written in the final published standard. It is however written in Nicolai Josuttis' updated C++11 "The C++ standard library" in the chapter on C++11 core language changes. And if you think it through, there has to be in practice ABI breakage in 03 ABIs because no one could have anticipated during their design of what 11 would require [1]. [1]: This may not apply to GCC as it revised its ABI quite recently, and I'm sure its designers took into account likely future 11 requirements. > The standard says nothing about "libraries/shared objects" I know only too well. I have an early draft for shared library implementation on my desk for WG14. It's too ambitious for WG14 as it explicitly adds interop for non-C languages. > 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. Sure. Any C++ implementation may choose to go beyond what is needed. However, I personally can see lots of potential for monsters to lurk there. I think the proposed debug aid will save a lot of time for a lot of people in the long run, and for the cost of implementation and almost nil cost of maintenance I'd just go ahead and implement it if I were ye. Which I'm not, so all I can do is try to persuade and advocate. Niall