From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1730 invoked by alias); 4 Jan 2012 12:54:28 -0000 Received: (qmail 1721 invoked by uid 22791); 4 Jan 2012 12:54:27 -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; Wed, 04 Jan 2012 12:54:15 +0000 From: "marc.glisse at normalesup dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/2316] g++ fails to overload on language linkage Date: Wed, 04 Jan 2012 12:54: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: ABI, accepts-invalid, rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: marc.glisse at normalesup dot org X-Bugzilla-Status: NEW 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-01/txt/msg00372.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2316 --- Comment #43 from Marc Glisse 2012-01-04 12:51:55 UTC --- (In reply to comment #40) > Great! If all existing code is accepted with a warning that provides backwards > compatibility, but also allows conforming code to correctly overload on > language linkage - that sounds ideal. Well, not all existing code, just the most common ones. For instance: templatestruct is_fun1{static const bool value=false;}; templatestruct is_fun1{static const bool value=true;}; will answer false for an extern "C" function type, and I am not sure how I could make it return true without breaking valid code too much (and you can call templatevoid f(F(T)); with an extern "C" function, but it has lower priority than template void f(T); or even void f(...);). But most uses in common code seem to be fine (it is even more lenient than sunCC, which fails to compile gcc because of extern "C"). Note that accepting these broken codes does imply we do the wrong thing on some valid code but I am hoping not too much. As a guiding principle, I tried to allow conversions only when there would be an error otherwise. > IMHO the warning should be controllable by something such as -Wlanguage-linkage > (since there will be lots of warnings in some codebases, so it needs to be > possible to use -Wall but disable these warnings) and the conversion should be > rejected with -pedantic-errors. Agreed, there's a lot of cleanup to do... (In reply to comment #41) > I would expect a lot of code to trigger this warning. It is quite common > to pass the address of a static member function to pthread_create but since > there is no way to make a static member function 'extern "C"', I can't see > how to do that without major contortions. I'm rather sure that this will > turn out to be an unpopular warning :-) libstdc++ does something like that in one place. As Jonathan told earlier, it would make sense to overload pthread_create so it can take a C++ function. The easiest way not to have the warning is to use a cast (not that this is very standard...). As for the popularity... I am still not sure we actually want to do this at all, this is a proof of concept to help make a decision.