From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29152 invoked by alias); 10 Jan 2011 15:47:06 -0000 Received: (qmail 29141 invoked by uid 22791); 10 Jan 2011 15:47:05 -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; Mon, 10 Jan 2011 15:47:01 +0000 From: "matz at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: rejects-valid X-Bugzilla-Severity: normal X-Bugzilla-Who: matz at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.4.0 X-Bugzilla-Changed-Fields: CC 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 Date: Mon, 10 Jan 2011 15:49:00 -0000 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-01/txt/msg00906.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511 Michael Matz changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matz at gcc dot gnu.org --- Comment #12 from Michael Matz 2011-01-10 15:46:31 UTC --- Jason: you're right that there are historically multiple uses of 'weak'. But they conflict with each other. If we regard it to merely allow equivalent definitions in several translation units, then we indeed could inline those, and the error Richard implemented would be wrong. _But_ we wouldn't be able to describe the usecase that I think is actually the one intended by the weak attribute, certainly the one that is deduced from its ELF meaning, namely to allow interposition of a different strong definition that isn't necessarily equivalent. For that latter definition we must disallow inlining. IMO we can't simply choose the first definition because it's broader than the second, and also because it goes against the ELF specification. If you need some attribute that follows the first definition I think it should not be named weak, but rather something like 'comdat'. Allow inline expansion, but also allow replacement by other definitions. For a Novell bug-report (I think it can't be accessed from the outside) I wrote this opinion about the connection between attribute weak and the several possibilities of describing visibility and inlining: ----------------------------------- I would propose the following semantics: a) an explicit visibility attribute takes precedence (hence if marked weak and hidden, the weakness is ignored), alternatively this should be a warning b) otherwise the symbol doesn't have explicit visibility, in other words it inherits from command line or block pragmas: in that case an additional weak attribute should cancel the visibility, as if it has default visibility (that will have the effect of disabling inlining, amongst other things) An explicit inline attribute on a weak function should generate a warning or error. ----------------------------------- To add your desired semantics: c) a 'comdat' attribute is compatible with inlining and visibility declarations (explicit or implicit) provided that all definitions of that symbol are marked 'comdat' and all of them are semantically equivalent