[Bug c/32511] [4.4/4.5/4.6 regression] GCC rejects inline+weak function

["matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32511

Michael Matz <matz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu.org

--- Comment #12 from Michael Matz <matz at gcc dot gnu.org> 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