[Bug tree-optimization/33763] [4.3/4.4/4.5/4.6 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[Bug tree-optimization/33763] [4.3/4.4/4.5/4.6 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-10-14 10:26:41         |2011-03-04 10:26:41
      Known to fail|                            |4.6.0

--- Comment #19 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-04 12:36:56 UTC ---
Still fails to inline baz (not a regression) and diagnoses this (this is
the regression).

> When a gnu_inline (or extern inline gnu89) function has a real is redefined, we
> don't want any inlining for that function even if it is always_inline, at least
> GCC always behaved that way and even on the simpler testcase behaves that way.

I don't think this is the desired behavior (nor is it documented).  If it is
then we should simply drop the always-inline attribute when merging the
function decls (basically throw away the inline definition).

[Bug tree-optimization/33763] [4.3/4.4/4.5/4.6 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[hubicka at ucw dot cz]

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

--- Comment #20 from Jan Hubicka <hubicka at ucw dot cz> 2011-03-05 12:45:29 UTC ---
> I don't think this is the desired behavior (nor is it documented).  If it is
> then we should simply drop the always-inline attribute when merging the
> function decls (basically throw away the inline definition).

Well, the desired behaviour IMO is to get one body for inline copies, other
body for offline copy (this is also only consistent interpretation with LTO.
Current way of inlining them early and then droppipng is bit weird).  This is
quite easy to do at cgraph level once frontend is able to produce both function
bodies at two different declarations (one static inline, other external) tells
so to the backend.
No one volunteed to do this at frontend side yet :(

Honza

[Bug tree-optimization/33763] [4.3/4.4/4.5/4.6 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[pthaugen at gcc dot gnu.org]

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

Pat Haugen <pthaugen at gcc dot gnu.org> changed:

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

--- Comment #21 from Pat Haugen <pthaugen at gcc dot gnu.org> 2011-03-11 22:16:12 UTC ---
An example from libhugetlbfs. Note the original call wasn't recursive,
following is reduced code I got from delta.

$ cat gethugepagesizes.c 
extern __inline __attribute__ ((__always_inline__))
     int open (__const char *__path, int __oflag, ...)
{
}

void cleanup (void);
open (const char *file, int flags, ...)
{
  char fname[4096 + 1];
  int fd;
  cleanup ();
  fd = open (fname, 01 | 0100);
}

void cleanup (void)
{
  cleanup_fake_data ();
}
$ ~/install/gcc/trunk/bin/gcc -O3 -c gethugepagesizes.c
gethugepagesizes.c: In function 'open':
gethugepagesizes.c:7:1: sorry, unimplemented: inlining failed in call to
'open': redefined extern inline functions are not considered for inlining
gethugepagesizes.c:12:6: sorry, unimplemented: called from here

[Bug tree-optimization/33763] [4.3/4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #22 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-06-27 12:14:32 UTC ---
4.3 branch is being closed, moving to 4.4.7 target.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |jsm28 at gcc dot gnu.org
          Component|tree-optimization           |c

--- Comment #23 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 13:42:39 UTC ---
Shorter testcase

extern __inline __attribute__ ((__always_inline__,__gnu_inline__))
void open ()
{
}
void open ()
{
  open ();
}

fails on trunk like

> ./cc1 -quiet t.c -O
t.c: In function 'open':
t.c:5:6: error: inlining failed in call to always_inline 'open': function not
inlinable
t.c:7:8: error: called from here

and creates wrong code at -O0 (and probably would, at -On):

open:
.LFB1:
        .cfi_startproc
        pushq   %rbp
        .cfi_def_cfa_offset 16
        .cfi_offset 6, -16
        movq    %rsp, %rbp
        .cfi_def_cfa_register 6
        movl    $0, %eax
        call    open
        popq    %rbp
        .cfi_def_cfa 7, 8
        ret

as the always-inline body was not inlined.

Note that the initial callgraph is already wrong:

Initial callgraph:

open/0 @0x7ffff5a2b6c0 (asm: open) analyzed needed reachable body finalized
redefined_extern_inline
  called by: open/0 (1.00 per call)
  calls: open/0 (1.00 per call)
  References:
  Refering this function:
variable pool:

as said, the C frontend needs to create two decls for open for this to
properly work.

OTOH, it is time to deprecate this extension and warn about it (after
all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce
the recursive open - how was this intended to work? ...)  I don't have
3.2 (and 2.95 does not have always_inline).

The "proper" way to write the testcase is

extern __inline __attribute__ ((__always_inline__,__gnu_inline__))
void open ()
{
}
void open_1 () asm("open");
void open_1 ()
{
  open ();
}

So, Joseph - would you be fine with changing behavior for this testcase
from ICEing at -On, miscompiling at -O0 to rejecting it?  Thus,

Index: c-decl.c
===================================================================
--- c-decl.c    (revision 183121)
+++ c-decl.c    (working copy)
@@ -1855,21 +1855,10 @@ diagnose_mismatched_decls (tree newdecl,
        {
          if (DECL_INITIAL (olddecl))
            {
-             /* If both decls are in the same TU and the new declaration
-                isn't overriding an extern inline reject the new decl.
+             /* If both decls are in the same TU reject the new decl.
                 In c99, no overriding is allowed in the same translation
                 unit.  */
-             if ((!DECL_EXTERN_INLINE (olddecl)
-                  || DECL_EXTERN_INLINE (newdecl)
-                  || (!flag_gnu89_inline
-                      && (!DECL_DECLARED_INLINE_P (olddecl)
-                          || !lookup_attribute ("gnu_inline",
-                                                DECL_ATTRIBUTES (olddecl)))
-                      && (!DECL_DECLARED_INLINE_P (newdecl)
-                          || !lookup_attribute ("gnu_inline",
-                                                DECL_ATTRIBUTES (newdecl))))
-                 )
-                 && same_translation_unit_p (newdecl, olddecl))
+             if (same_translation_unit_p (newdecl, olddecl))
                {
                  error ("redefinition of %q+D", newdecl);
                  locate_old_decl (olddecl);

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[hubicka at ucw dot cz]

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

--- Comment #24 from Jan Hubicka <hubicka at ucw dot cz> 2012-01-12 14:22:52 UTC ---
> OTOH, it is time to deprecate this extension and warn about it (after
> all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce
> the recursive open - how was this intended to work? ...)  I don't have
> 3.2 (and 2.95 does not have always_inline).

pre cgraph compilers handled it in a way that inline body was kept after
parsing
extern inline version and inlined into every new parsed function until
the offline version was reached. Then the function was marked uninlinable,
offline body was produced and all subsequentely parsed calls was not inlined
(including calls in the offline body).

I think extern inlines are sadly rather common to be deprecated...

Honza

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenther at suse dot de]

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

--- Comment #25 from rguenther at suse dot de <rguenther at suse dot de> 2012-01-12 14:27:12 UTC ---
On Thu, 12 Jan 2012, hubicka at ucw dot cz wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
> 
> --- Comment #24 from Jan Hubicka <hubicka at ucw dot cz> 2012-01-12 14:22:52 UTC ---
> > OTOH, it is time to deprecate this extension and warn about it (after
> > all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce
> > the recursive open - how was this intended to work? ...)  I don't have
> > 3.2 (and 2.95 does not have always_inline).
> 
> pre cgraph compilers handled it in a way that inline body was kept after
> parsing
> extern inline version and inlined into every new parsed function until
> the offline version was reached. Then the function was marked uninlinable,
> offline body was produced and all subsequentely parsed calls was not inlined
> (including calls in the offline body).
> 
> I think extern inlines are sadly rather common to be deprecated...

Well, not deprecating extern inlines but re-definitions in the
same TU which miscompiles once the extern inline is used in that
TU (ok, so you can say in 99% of all cases that won't happen).

Thus, another workaround would be to avoid transitioning the
attribute to the redefinition in merge_decls (under the exact
same condition as we allow the redefinition).

Richard.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 14:31:28 UTC ---
(In reply to comment #25)
> On Thu, 12 Jan 2012, hubicka at ucw dot cz wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
> > 
> > --- Comment #24 from Jan Hubicka <hubicka at ucw dot cz> 2012-01-12 14:22:52 UTC ---
> > > OTOH, it is time to deprecate this extension and warn about it (after
> > > all we miscompile this since quite some time, GCC 3.3 and 4.1 already produce
> > > the recursive open - how was this intended to work? ...)  I don't have
> > > 3.2 (and 2.95 does not have always_inline).
> > 
> > pre cgraph compilers handled it in a way that inline body was kept after
> > parsing
> > extern inline version and inlined into every new parsed function until
> > the offline version was reached. Then the function was marked uninlinable,
> > offline body was produced and all subsequentely parsed calls was not inlined
> > (including calls in the offline body).
> > 
> > I think extern inlines are sadly rather common to be deprecated...
> 
> Well, not deprecating extern inlines but re-definitions in the
> same TU which miscompiles once the extern inline is used in that
> TU (ok, so you can say in 99% of all cases that won't happen).
> 
> Thus, another workaround would be to avoid transitioning the
> attribute to the redefinition in merge_decls (under the exact
> same condition as we allow the redefinition).

Only a workaround for the ICE, of course, not the miscompile (can
anyone check if we ever did not miscompile this case?)

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 14:30:31 UTC ---
The patch fails to bootstrap in libquadmath btw:

/space/rguenther/src/svn/trunk/libquadmath/math/cimagq.c:24:1: error:
redefinition of 'cimagq'
In file included from
/space/rguenther/src/svn/trunk/libquadmath/quadmath-imp.h:26:0,
                 from
/space/rguenther/src/svn/trunk/libquadmath/math/cimagq.c:21:
/space/rguenther/src/svn/trunk/libquadmath/quadmath.h:175:1: note: previous
definition of 'cimagq' was here
make[3]: *** [math/cimagq.lo] Error 1

which seems to make heavy use of gnu-inline always-inline.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[joseph at codesourcery dot com]

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

--- Comment #28 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-01-12 14:35:58 UTC ---
On Thu, 12 Jan 2012, rguenther at suse dot de wrote:

> > I think extern inlines are sadly rather common to be deprecated...
> 
> Well, not deprecating extern inlines but re-definitions in the
> same TU which miscompiles once the extern inline is used in that
> TU (ok, so you can say in 99% of all cases that won't happen).

I haven't tested it, but I'd expect extern inline + redefinition to be 
occur in various cases building glibc, or any other library with extern 
inlines in its headers.  Though those cases may be less likely then to use 
the redefined function in the same TU.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #29 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 14:49:42 UTC ---
Btw, GCC 3.2.3 produces for

extern __inline __attribute__ ((__always_inline__))
void open ()
{
}
void open ()
{
  open ();
}

open:
        pushl   %ebp
        movl    %esp, %ebp
        call    open
        popl    %ebp
        ret

so it's "broken" as well.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #30 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-12 14:54:04 UTC ---
Of course the question is what we should really do here wrt name-lookup.

[Bug c/33763] [4.4/4.5/4.6/4.7 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-13 09:26:45 UTC ---
Ok, so the following patch makes

extern __inline __attribute__ ((__always_inline__))
void open ()
{
}
void bar ()
{
  open ();
}
void open ()
{
  open ();
}

"work" as in the extern inline variant is used for the callin bar()
and the call in open () is recursive and all following calls would
refer to it.  That means, we end up with two cgraph nodes (but do
not magically use one for inlining and one for the offline copy - that
would need to be fixed in the C frontend by _not_ changing name-lookup
to lookup the 2nd version, but I'm not sure that is desired).

At least you can say the behavior makes sense and it avoids the ICEs, too.

I'm going to test this.

Index: gcc/c-decl.c
===================================================================
--- gcc/c-decl.c        (revision 183121)
+++ gcc/c-decl.c        (working copy)
@@ -2513,6 +2513,24 @@ duplicate_decls (tree newdecl, tree oldd
       return false;
     }

+  /* If we have a redeclared extern inline function simply drop olddecl
+     on the floor instead of merging it with newdecl.  */
+  if (TREE_CODE (newdecl) == FUNCTION_DECL
+      && DECL_INITIAL (newdecl)
+      && DECL_INITIAL (olddecl)
+      && !(!(DECL_DECLARED_INLINE_P (olddecl)
+            && DECL_EXTERNAL (olddecl))
+          || (DECL_DECLARED_INLINE_P (newdecl)
+              && DECL_EXTERNAL (newdecl))
+          || (!flag_gnu89_inline
+              && (!DECL_DECLARED_INLINE_P (olddecl)
+                  || !lookup_attribute ("gnu_inline",
+                                        DECL_ATTRIBUTES (olddecl)))
+              && (!DECL_DECLARED_INLINE_P (newdecl)
+                  || !lookup_attribute ("gnu_inline",
+                                        DECL_ATTRIBUTES (newdecl))))))
+    return false;
+
   merge_decls (newdecl, olddecl, newtype, oldtype);
   return true;
 }

[Bug c/33763] [4.5/4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug c/33763] [4.5/4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #33 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-02 11:50:11 UTC ---
The 4.5 branch is being closed, adjusting target milestone.

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[dschepler at gmail dot com]

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

Daniel Schepler <dschepler at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dschepler at gmail dot com

--- Comment #34 from Daniel Schepler <dschepler at gmail dot com> 2012-07-09 15:02:42 UTC ---
(In reply to comment #31)
Just so you know, the proposed patch would break glibc builds.  Here's a
reduced test case that reproduces an issue compiling glibc's s_isnan.c on
amd64...

extern int foo() __attribute__((__const__, __nothrow__));
extern int foo() __asm__("__GI_foo") __attribute__ ((visibility("hidden")));
extern __inline int __attribute__((__always_inline__)) foo() {
  return 0;
}
int foo() {
  return 0;
}
extern __typeof__(foo) __EI_foo __asm__("foo")
__attribute__((alias("__GI_foo")));

On Debian, gcc-4.6 compiles this code OK, while gcc-4.7 (which has this patch
applied) errors out with:
/tmp/pr33763_broken.c:9:24: error: '__EI_foo' aliased to external symbol
'__GI_foo'

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[rguenth at gcc dot gnu.org]

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

--- Comment #35 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-07-09 15:39:35 UTC ---
(In reply to comment #34)
> (In reply to comment #31)
> Just so you know, the proposed patch would break glibc builds.  Here's a
> reduced test case that reproduces an issue compiling glibc's s_isnan.c on
> amd64...
> 
> extern int foo() __attribute__((__const__, __nothrow__));
> extern int foo() __asm__("__GI_foo") __attribute__ ((visibility("hidden")));
> extern __inline int __attribute__((__always_inline__)) foo() {
>   return 0;
> }
> int foo() {
>   return 0;
> }
> extern __typeof__(foo) __EI_foo __asm__("foo")
> __attribute__((alias("__GI_foo")));
> 
> On Debian, gcc-4.6 compiles this code OK, while gcc-4.7 (which has this patch
> applied) errors out with:
> /tmp/pr33763_broken.c:9:24: error: '__EI_foo' aliased to external symbol
> '__GI_foo'

Yes, I know - the patch had fallout in the testsuite and I dropped the ball
on this bugreport.

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-05 11:43:43 UTC ---
Author: jakub
Date: Fri Oct  5 11:43:38 2012
New Revision: 192119

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192119
Log:
    PR tree-optimization/33763
    * tree-inline.c (expand_call_inline): Silently ignore always_inline
    attribute for redefined extern inline functions.

    * c-c++-common/pr33763.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr33763.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-inline.c

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-05 11:58:49 UTC ---
Author: jakub
Date: Fri Oct  5 11:58:46 2012
New Revision: 192121

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192121
Log:
    PR tree-optimization/33763
    * tree-inline.c (expand_call_inline): Silently ignore always_inline
    attribute for redefined extern inline functions.

    * c-c++-common/pr33763.c: New test.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/c-c++-common/pr33763.c
Modified:
    branches/gcc-4_7-branch/gcc/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/tree-inline.c

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

--- Comment #38 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-05 12:02:03 UTC ---
Author: jakub
Date: Fri Oct  5 12:01:59 2012
New Revision: 192122

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192122
Log:
    PR tree-optimization/33763
    * tree-inline.c (expand_call_inline): Silently ignore always_inline
    attribute for redefined extern inline functions.

    * c-c++-common/pr33763.c: New test.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/c-c++-common/pr33763.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-inline.c

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[steven at gcc dot gnu.org]

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #39 from Steven Bosscher <steven at gcc dot gnu.org> 2012-11-11 21:27:12 UTC ---
Is there still a bug here, after the commits of comment #36 to #38?

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |FIXED

--- Comment #40 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-11 21:28:46 UTC ---
Fixed.

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[kaltsi+gnu at gmail dot com]

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

Juha Kallioinen <kaltsi+gnu at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kaltsi+gnu at gmail dot com

--- Comment #41 from Juha Kallioinen <kaltsi+gnu at gmail dot com> ---
Maybe this failure with a newly built gcc 4.8 is related to this bug.

Built gcc today from
commit a846b696b9f3e9b9caab7e43ef8450cbded2715c
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch@202762
138bc75d-0d04-0410-961f-82ee72b

~/gcc48/bin$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/home/kaltsi/gcc48/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/kaltsi/gcc48
--disable-bootstrap --with-tune=generic --disable-multilib
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object --enable-lto
--enable-linker-build-id --enable-languages=c,c++ --enable-threads=posix
--enable-shared --disable-libgcj
Thread model: posix
gcc version 4.8.2 20130920 (prerelease) (GCC) 

Compiling the following simple program with these options on an Ubuntu 12.04
causes a failure:

$ gcc -Wp,-D_FORTIFY_SOURCE=2 -O2 -D_GNU_SOURCE=1




-- foo.c --
#include <sys/socket.h>

extern ssize_t recvfrom(int s, void *buf, size_t len, int flags, struct
sockaddr *from, socklen_t *fromlen);

int main()
{
  int s, flags; void *buf; size_t len; struct sockaddr *from; socklen_t*
fromlen;
  return(recvfrom(s, buf, len, flags, from, fromlen));
}

-- foo.c --

~/gcc48/bin$ ./gcc -Wp,-D_FORTIFY_SOURCE=2 -O2 -D_GNU_SOURCE=1 foo.c
In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:251:0,
                 from foo.c:5:
foo.c: In function ‘main’:
/usr/include/x86_64-linux-gnu/bits/socket2.h:65:1: error: inlining failed in
call to always_inline ‘recvfrom’: mismatched arguments
 recvfrom (int __fd, void *__restrict __buf, size_t __n, int __flags,
 ^
foo.c:12:18: error: called from here
   return(recvfrom(s, buf, len, flags, from, fromlen));
                  ^
>From gcc-bugs-return-430326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 20 22:16:33 2013
Return-Path: <gcc-bugs-return-430326-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6584 invoked by alias); 20 Sep 2013 22:16:33 -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 6448 invoked by uid 48); 20 Sep 2013 22:16:31 -0000
From: "rogerdpack at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/16371] libstdc++ fails for crosses
Date: Fri, 20 Sep 2013 22:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 3.4.1
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rogerdpack at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-16371-4-yIixVDE01M@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16371-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16371-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-09/txt/msg01566.txt.bz2
Content-length: 861

http://gcc.gnu.org/bugzilla/show_bug.cgi?id\x16371

roger pack <rogerdpack at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rogerdpack at gmail dot com

--- Comment #27 from roger pack <rogerdpack at gmail dot com> ---
(sorry to comment on something so ancient).  Anyway ran into something similar
today, a couple of hints/clues: mine was caused by having an empty environment
variable CFLAGS (like bash's export CFLAGS=).  So unsetting that and I was good
to go.
Also (as others have noted) this error message basically means "your cross
compiler is unable to link at all" or something like that (the config.log that
may describe it is called something like
i686-w64-mingw32/libstdc++-v3/config.log)

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[jakub at gcc dot gnu.org]

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

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Juha Kallioinen from comment #41)
> Maybe this failure with a newly built gcc 4.8 is related to this bug.

No, that is just a buggy testcase.  Redefining a prototype, especially if you
have no idea how the system function prototype looks like, is a bug.
In the testcaseif you redefine the prototype to something different and
obviously it then fails to inline it.  Don't do that.

[Bug c/33763] [4.6/4.7/4.8 Regression] Bogus inlining failed in call to `xxx': redefined extern inline functions are not considered for inlining

[kaltsi+gnu at gmail dot com]

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

--- Comment #43 from Juha Kallioinen <kaltsi+gnu at gmail dot com> ---
(In reply to Jakub Jelinek from comment #42)
> (In reply to Juha Kallioinen from comment #41)
> > Maybe this failure with a newly built gcc 4.8 is related to this bug.
> 
> No, that is just a buggy testcase.  Redefining a prototype, especially if
> you have no idea how the system function prototype looks like, is a bug.
> In the testcaseif you redefine the prototype to something different and
> obviously it then fails to inline it.  Don't do that.

This was just a reduction of a piece of code that started to fail with gcc 4.8,
but compiles with earlier versions. I'll try to understand what is different in
the prototype redefinition.