[Bug regression/49139] New: always_inline attribute inconsistencies

[chrbr at gcc dot gnu.org]

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

           Summary: always_inline attribute inconsistencies
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: regression
        AssignedTo: unassig...@gcc.gnu.org
        ReportedBy: ch...@gcc.gnu.org


Created attachment 24340
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24340
fails even without -Winline

Hello,

I'm wondering whether or not the always_inline in PIC must prevails over the
general preemption rules. Apparently not accordingly to the default behavior
for the compilation in -O2 -fpic of

__attribute((always_inline)) void bar() { }

void test(void)
{
  bar();
}

foo.c:1:35: sorry, unimplemented: inlining failed in call to 'bar': function
body can be overwriten at linktime
foo.c:5:6: sorry, unimplemented: called from here

First (1): inlining cannot be done, So without -Werror, this should be a
warning, not a "sorry error". 

Or (2): The function could be inlined, despite the preemption rule. But it is
just not yet implemented. In this case.

In case of (1), I'm attaching here a C++ reduced piece of code that triggers
this error even without using -Winline, making the error quite unpredictable,
since this depends of the presence of another inlined call (here, "Alloc"),
forcing a call to "expand_call_inline" producing the same effect than -Winline
(as shown with a breakpoint in ipa-inline-transform:306 on trunk)

So which one of the strategies is good: Fixing the warning, and make sure that
it only (and consistently) occurs when -Winline is used, or always honoring the
always_inline attribute despite visibility potential issues, considering that a
user directive bypass the defaults ?

Thanks, 
Christian