[Bug c++/62282] New: Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[Bug c++/62282] New: Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[dmitry.petroff at gmail dot com]

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

            Bug ID: 62282
           Summary: Undefined reference with __inline
                    __attribute(__gnu_inline__) with -O0
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dmitry.petroff at gmail dot com

The following code produces "undefined reference to `test(int)'" message when
compiled with g++ -O0 test.cpp:

// == cut ==
__inline
__attribute__ ((__gnu_inline__))
int test(int v)
{
    return v;
}

int main(int argc, char **argv)
{
    return test(argc);
}
// == cut ==

It links successfully in C mode.
This bug breaks for me usage of gperf's C output in C++ code with simple
"include" directive.

[Bug c++/62282] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-27
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The docs for gnu_inline for C++ are a bit vague (what special
behavior?  it seems it treats it as 'extern' regardless of that being present
or not?)

Thus, either a C++ FE or documentation bug.

[Bug c++/62282] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Except it is not vague in general, the idea is that there is another definition
somewhere of test and not just in this translation unit. Since we are at -O0,
we decide not to inline it and it does not get emitted.

[Bug c++/62282] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[dmitry.petroff at gmail dot com]

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

--- Comment #3 from Dmitry Petrov <dmitry.petroff at gmail dot com> ---
Created attachment 33408
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33408&action=edit
g++ + gperf bug in action

Guys, I'm software developer myself and I can understand your attitute to
"declare bug as a feature". But please note, that this bug is breaking normal
development with gperf which is also a GNU tool.

In the attached archive try
make => failure in compiling bug++
make CFLAGS=-O => success, inlining happens
make CXX=clang++ => success

You're saying "we've designed this extension and it works as it should". But
why gcc links this successfully, but g++ don't? It looks like either C or C++
compiler bug.

P. S. I'm using gperf to generate code for both C server-side and C++
tools/testcases and such g++ behaviour is really unpleasing when making debug
builds.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
      Known to work|                            |4.2.4
         Resolution|INVALID                     |---
   Target Milestone|---                         |4.8.4
            Summary|Undefined reference with    |[4.8/4.9/5 Regression]
                   |__inline                    |Undefined reference with
                   |__attribute(__gnu_inline__) |__inline
                   |with -O0                    |__attribute(__gnu_inline__)
                   |                            |with -O0
      Known to fail|                            |4.3.6

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> Except it is not vague in general, the idea is that there is another
> definition somewhere of test and not just in this translation unit. Since we
> are at -O0, we decide not to inline it and it does not get emitted.

So with C++ 'inline __attribute__((__gnu_inline__))' is equivalent to
'extern inline __attribute__((__gnu_inline__))'?  What's the reason for
that?

It seems it is at least inconsistent with pre-c99 inline semantic?

G++ 4.1 links the test just fine (G++ 4.3 already shows the bad behavior),
but G++ 4.1 also links 'extern inline' fine (but it doesn't inline).

At least it's very old behavior it seeems, but a regression from G++ 4.2
which knows the attribute but correctly preserves the function(?).

Note that the C frontend happily links the testcase as well, preserving
the function.  That's an inconvenient difference between behavior of
C and C++ for an attribute that was introduced to provide backward
compatibility with pre-C99 inline semantics.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |jsm28 at gcc dot gnu.org

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Jason?  Joseph?

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd say it is a user bug, you shouldn't use gnu_inline attribute on a function
that is not extern inline.  Why do you want that?  Either you want extern
inline __attribute__((gnu_inline)), which will act as the GNU extern inline
function (if inlined successfully, fine, otherwise you need to supply external
definition), or you want normal C++ inline semantics.  inline
__attribute__((gnu_inline)) doesn't make sense.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why is this marked as a regression btw?  From what I can see, already G++ 4.3
behaved this way, and G++ 4.3 was the first release to support gnu_inline
attribute in C++.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And it is even documented:
In C++, this attribute does not depend on 'extern' in any way, but
it still requires the 'inline' keyword to enable its special
behavior.
The special behavior is explained in the earlier paragraphs of gnu_inline
attribute description.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[dmitry.petroff at gmail dot com]

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

Dmitry Petrov <dmitry.petroff at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---

--- Comment #9 from Dmitry Petrov <dmitry.petroff at gmail dot com> ---
Jakub, so you telling that different behaviour of gcc and g++ is ok in this
case? With gcc inline + gnu_inline does not yields undefined references.

And before you advice me to not use such constructions in my code, please note
that problem appears in gperf output. So people have to use ugly #undef
workarounds or even more ugly sed tricks or just don't use gperf's C output
with g++ when debugging.

And I'm sorry to be that insistent but
>G++ 4.3 was the first release to support gnu_inline attribute in C++
is not true: g++-4.1 supported gnu_inline at some point:
http://www.redhat.com/archives/fedora-extras-commits/2007-September/msg00089.html

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |INVALID

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Dmitry Petrov from comment #9)
> Jakub, so you telling that different behaviour of gcc and g++ is ok in this
> case?

Yes.

> With gcc inline + gnu_inline does not yields undefined references.

C++ has one inline semantics, C99 another one (different from C++), GNU89
another one.  So, why do you expect some consistency?
The gnu_inline attribute allows to tweak what semantics it is.
In C99 mode, where since 4.3 the default is the C99 semantics, gnu_inline
attribute tells the compiler to use GNU89 inline semantics anyway.  That
semantics is about all of inline, extern inline, static inline and various
combinations of those on duplicate declarations/definitions.
In C++ mode, all we needed was the GNU89 extern inline semantics, so the
gnu_inline attribute in C++ is about that.

> And before you advice me to not use such constructions in my code, please
> note that problem appears in gperf output. So people have to use ugly #undef
> workarounds or even more ugly sed tricks or just don't use gperf's C output
> with g++ when debugging.

Why don't you emit it conditional on __cpluplus macro or similar?
Which of the above mentioned semantics you want for your inlines?

> And I'm sorry to be that insistent but
> >G++ 4.3 was the first release to support gnu_inline attribute in C++
> is not true: g++-4.1 supported gnu_inline at some point:
> http://www.redhat.com/archives/fedora-extras-commits/2007-September/msg00089.
> html

4.1 doesn't support it in C++ mode, only some vendor compilers like 4.1-RH
(perhaps others) have some changes backported.  Vanilla 4.1 was the first gcc
version to support it in C mode though.

[Bug c++/62282] [4.8/4.9/5 Regression] Undefined reference with __inline __attribute(__gnu_inline__) with -O0

[dmitry.petroff at gmail dot com]

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

--- Comment #11 from Dmitry Petrov <dmitry.petroff at gmail dot com> ---
>Which of the above mentioned semantics you want for your inlines?
Semantics that would allow me get code that links even with -O0 without need to
dublicate function body.

I can understand how this code can produce an undefined reference:

// === cut ===
__inline
__attribute__ ((__gnu_inline__))
int test(int v)
{
    return v;
}

int main(int argc, char **argv)
{
    return test(argc);
}
// === cut ===

With -O0 gcc is not inlining, then __inline + gnu_inline comes into play by
prohibiting generation test's body. So there's main function that has "call
U(_Z4testi)" instruction but there's no way to actually get test address. That
is logical, but insane.

Is there an easy way to get debugger-friendly (-O0) compiler output other than
provide an exact function copy but without __inline
__attribute__((__gnu_inline__))?
>From what I see, I have to pipe gperf's output to sed -e
's/__gnu__inline__/\0,__always_inline__/', but this seems so ugly that GNU
tools cannot cooperate with each other.