[Bug c/59197] New: An alias from an always_inline function causes inconsistent behavior

[Bug c/59197] New: An alias from an always_inline function causes inconsistent behavior

[luto at mit dot edu]

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

            Bug ID: 59197
           Summary: An alias from an always_inline function causes
                    inconsistent behavior
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luto at mit dot edu

This program:

extern void func(void);
extern __inline __attribute__((__always_inline__))
__attribute__((__gnu_inline__)) void func(void) { }

extern void alias_target_func(void) {}
extern void func(void) __attribute__((alias("alias_target_func")));

extern void caller(void)
{
  func();
}

fails to compile on 4.7, 4.8, and trunk with -c -fPIC -O2, saying:

inline_alias.c: In function ‘caller’:
inline_alias.c:5:13: error: inlining failed in call to always_inline ‘func’:
function body can be overwritten at link time
 extern void func(void) __attribute__((alias("alias_target_func")));
             ^
inline_alias.c:9:7: error: called from here
   func();
       ^

It compiles on an old copy of gcc 4.5 I have lying around, although I don't
think I agree with the generated code.

gcc 4.5.1 (and gcc 4.8.2 with -O0) emit the call to func.  With the alias
removed, the call to func is not emitted, even at -O0.  Oddly, without -fPIC,
gcc 4.8 and trunk inline the call to func.

trunk's behavior with -O0 (w/o -fPIC) is even stranger: it emits a call to
alias_target_func.  I can't reproduce that with other flags or on gcc 4.8.

I think that the correct behavior would be to either (a) reject the alias as a
redefinition of func or (b) accept this code as valid and inline func.  Given
the documented behavior for "extern __attribute__((gnu_inline))", the inline
version of func should be used (or this code should be rejected outright).

This may be related to PR33763 or PR46596, but I don't think it's the same
issue as either one, although the respective fixes could be involved in the
behavior changes.

It came up in practice when openonload-201310 failed to build with
_FORTIFY_SOURCE=2.
>From gcc-bugs-return-435156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Nov 20 01:10:50 2013
Return-Path: <gcc-bugs-return-435156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25793 invoked by alias); 20 Nov 2013 01:10:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25435 invoked by uid 48); 20 Nov 2013 01:10:12 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/48801] uninitialized warning for variables used only in loop body and initialized in the first iteration
Date: Wed, 20 Nov 2013 01:10: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-Version: 4.6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-48801-4-yx8YBxfdWa@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48801-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48801-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-11/txt/msg01933.txt.bz2
Content-length: 539

http://gcc.gnu.org/bugzilla/show_bug.cgi?idH801

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |law at redhat dot com
         Resolution|---                         |WORKSFORME

--- Comment #2 from Jeffrey A. Law <law at redhat dot com> ---
gcc-4.8 and the trunk seem to handle this just fine.

[Bug c/59197] An alias from an always_inline function causes inconsistent behavior

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-20
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
And with

extern void func(void);
extern void func(void) __attribute__((alias("alias_target_func")));

extern __inline __attribute__((__always_inline__))
__attribute__((__gnu_inline__)) void func(void) { }

extern void alias_target_func(void) {}

extern void caller(void)
{
    func();
}

you get

t.c:4:89: error: redefinition of 'func'
 extern __inline __attribute__((__always_inline__))
__attribute__((__gnu_inline__)) void func(void) { }
                                                                               
         ^
t.c:2:13: note: previous definition of 'func' was here
 extern void func(void) __attribute__((alias("alias_target_func")));
             ^

even though I'd say that providing an extern inline definition should
still work?

But yeah, gnu extern inlines have interesting behavior...

[Bug c/59197] An alias from an always_inline function causes inconsistent behavior

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59197

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup.

[Bug c/59197] An alias from an always_inline function causes inconsistent behavior

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59197

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|NEW                         |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

*** This bug has been marked as a duplicate of bug 46596 ***