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

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
         AssignedTo|rguenth at gcc dot gnu.org  |unassigned at gcc dot
                   |                            |gnu.org

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-09-30 11:00:53 UTC ---
This bug has turned into a different one.  Not working on it.

In future please open new bugs instead of re-opening them and changing
them into sth completely different.

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

[jason at gcc dot gnu.org]

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

--- Comment #11 from Jason Merrill <jason at gcc dot gnu.org> 2010-09-30 16:01:01 UTC ---
I don't see it as different at all; I am arguing that the initial bug report
was not actually a bug, and that the patch should be reverted.

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

[matz at gcc dot 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

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

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-10 15:48:51 UTC ---
The original problem was fixed for GCC 4.6 with

2010-09-24  Jan Hubicka  <jh@suse.cz>

        * lto-symtab.c (lto_symtab_entry_def): Add guessed field.
        (lto_symtab_resolve_symbols): Set it.
...
        * tree.h (DECL_REPLACEABLE_P): Remove.
        (decl_replaceable_p, decl_binds_to_current_def_p): Declare.
...
        * varasm.c (resolution_to_local_definition_p, resolution_local_p): New
        static functions.
        (default_binds_local_p_1): Use resolutoin info.
        (decl_binds_to_current_def_p, decl_replaceable_p): New functions.
...

thus the patch can be reverted on the trunk (I'll do that after a round
of testing).

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

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
      Known to work|                            |4.6.0
            Summary|[4.4/4.5/4.6 regression]    |[4.4/4.5 Regression] GCC
                   |GCC rejects inline+weak     |rejects inline+weak
                   |function                    |function

--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 10:09:51 UTC ---
Fixed on trunk (both bugs).

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

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-11 10:09:19 UTC ---
Author: rguenth
Date: Tue Jan 11 10:09:15 2011
New Revision: 168652

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168652
Log:
2011-01-12  Richard Guenther  <rguenther@suse.de>

    PR middle-end/32511
    * c-common.c (handle_weak_attribute): Warn instead of error
    on declaring an inline function weak.

    * gcc.dg/attr-weak-1.c: Adjust.

Modified:
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/attr-weak-1.c

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.0                       |4.4.7

[Bug c/32511] [4.5 Regression] GCC rejects inline+weak function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.4.7                       |4.5.4

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-13 12:47:21 UTC ---
4.4 branch is being closed, moving to 4.5.4 target.

[Bug c/32511] [4.5 Regression] GCC rejects inline+weak function

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|4.5.4                       |4.6.0

--- Comment #17 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 09:27:15 UTC ---
Fixed for 4.6.0

[Bug c/32511] New: GCC inlines weak function

[sabre at nondot dot org]

GCC generally doesn't inline weak functions, because their body may be
redefined by the linker: if the compiler inlined the call, the linker changing
the behavior of the function wouldn't change the inlined copy.  For example,
GCC does not inline this:

void bar () __attribute__((weak));
void bar () {}
void foo() { bar(); } 

However, GCC apparently overrides this if the inline keyword is added (and
potentially if the weak function is defined in a c++ class where it would be
implicit inline?).  As such, it cause the following to be inlined:

inline void bar () __attribute__((weak));
void bar () {}
void foo() { bar(); } 

However, again, this breaks the semantics of weak linkage.  If bar is redefined
at link-time, the inlined copy is not updated.  Because 'inline' is an
optimization request, not a requirement, it seems best for the compiler to
ignore the inline request in this case.

-Chris


-- 
           Summary: GCC inlines weak function
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: sabre at nondot dot org


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

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

[jason at gcc dot gnu dot org]

------- Comment #9 from jason at gcc dot gnu dot org  2010-07-12 13:46 -------
Marking as regression.  Weak symbols have multiple uses: allowing replacement
is one, but they are also used to allow equivalent definitions in multiple
translation units without linker errors.


-- 

jason at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid, wrong-code |rejects-valid
            Summary|GCC inlines weak function   |[4.4/4.5/4.6 regression] GCC
                   |                            |rejects inline+weak function


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