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

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

[jakub at gcc dot gnu dot org]

/* { dg-do compile } */
/* { dg-options "-O2" } */

typedef struct
{
  void *a;
  void *b;
} T;
extern void *foo (const char *, const char *);
extern void *bar (void *, const char *, T);
extern int baz (const char *, int);

extern inline __attribute__ ((always_inline, gnu_inline)) int
baz (const char *x, int y)
{
  return 2;
}

int
baz (const char *x, int y)
{
  return 1;
}

int xa, xb;

static void *
inl (const char *x, const char *y)
{
  T t = { &xa, &xb };
  int *f = (int *) __builtin_malloc (sizeof (int));
  const char *z;
  int o = 0;
  void *r = 0;

  for (z = y; *z; z++)
    {
      if (*z == 'r')
        o |= 1;
      if (*z == 'w')
        o |= 2;
    }
  if (o == 1)
    *f = baz (x, 0);
  if (o == 2)
    *f = baz (x, 1);
  if (o == 3)
    *f = baz (x, 2);

  if (o && *f > 0)
    r = bar (f, "w", t);
  return r;
}

void *
foo (const char *x, const char *y)
{
  return inl (x, y);
}

issues bogus sorry diagnostics, while simpler testcases are handled just fine:
extern int foo (const char *, int);
extern int baz (const char *, int);

extern inline __attribute__ ((always_inline, gnu_inline)) int
baz (const char *x, int y)
{
  return 2;
}

int
baz (const char *x, int y)
{
  return 1;
}

int xa, xb;

static int
inl (const char *x, int y)
{
  return baz (x, y);
}

int
foo (const char *x, int y)
{
  return inl (x, y);
}

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.
Even the original testcase works just fine with GCC 3.2.x, so this is a
regression.  On the trunk it is enough to e.g. remove one of the 3 baz calls in
inl and it compiles just fine (none of the baz calls is inlined as expected),
but
e.g. on 4.1 branch the compilation still fails.

arts hits this problem when building against recent glibcs.


-- 
           Summary: [4.1/4.2/4.3 Regression] Bogus inlining failed in call
                    to `xxx': redefined extern inline functions are not
                    considered for inlining
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jakub at gcc dot gnu dot org


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2007-10-14 10:26 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-10-14 10:26:41
               date|                            |
   Target Milestone|---                         |4.2.3


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #2 from hubicka at gcc dot gnu dot org  2007-10-14 12:10 -------
This is result of ugly hack handling redefined extern inline functions.  The
most sane semantics (not what 3.2.x did) would be that function if inlined
should get the extern inline body, but the body from redefined non-extern
inline function should be output off-line and used when called.

Cgraph code can deal with this via cgraph->global->inline_decl.  The problem is
that frontend currently behave in a way parsing extern inline body and
finalizing it in a cgraph, but before unit is finished and cgraph has chance to
use it, the redefinition overwrite the body.

If frontend was updated to produce 2 separate declarations, one for the extern
inline body, one for the offline body and set the inline_decl of the second
declaration to point to first, things should just work.

There is one extra problem to this - extern inline functions are declared as
public and handled so by quite large part of compiler. This means that when
doing --combine (or future LTO), we end up having multiple copies of global
extern inline function and we end up not inlining them at all too.

I think frontend should be told to make those functions static (or we need to
update rest of fronend code to special case this)

Honza


-- 


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #3 from hubicka at gcc dot gnu dot org  2007-10-14 12:50 -------
This patch should disable the sorry message in this case, but I would argue
that outputting sorry here is right - we fail to inline alway_inline function
because of implementation limitation. So I would claim 3.2.0 being buggy rather
than mainline.

Honza

Index: tree-inline.c
===================================================================
*** tree-inline.c       (revision 129072)
--- tree-inline.c       (working copy)
*************** expand_call_inline (basic_block bb, tree
*** 2560,2565 ****
--- 2560,2571 ----
    if (!cgraph_inline_p (cg_edge, &reason))
      {
        if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (fn))
+         /* For extern inline functions that get redefined we always
+            silently ignored alway_inline flag. Better behaviour would
+            be to be able to keep both bodies and use extern inline body
+            for inlining, but we can't do that because frontends overwrite
+            the body.  */
+         && !cg_edge->callee->local.redefined_extern_inline
          /* Avoid warnings during early inline pass. */
          && (!flag_unit_at_a_time || cgraph_global_info_ready))
        {


-- 


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

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

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2007-10-14 21:10 -------
At least for gcc-4_1-branch and gcc-4_2-branch your patch is IMHO the best
thing we can do.  I agree that with cgraph it shouldn't be very hard to
actually
register two bodies, one for extern inline fn and one for the real definition,
but am not sure if such changes are appropriate this late in 4.3 development,
so
perhaps it should be applied also for 4.3 and early in 4.4 we should come up
with the real fixes.


-- 


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

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

[mmitchel at gcc dot gnu dot org]

-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-01-08 16:49 -------
I would suggest to go with the patch in comment #3.


-- 


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

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

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2008-01-08 17:25 -------
So do I and even am using that patch for quite some time in our gcc packages.
But Mark objected to that:
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00589.html
The current state of things is bad, because with glibc 2.7+ several valid
programs don't compile.  And this late in stage3 is probably dangerous to play
with two different bodies in cgraph.


-- 


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

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

[rguenther at suse dot de]

------- Comment #7 from rguenther at suse dot de  2008-01-08 17:27 -------
Subject: Re:  [4.1/4.2/4.3 Regression] Bogus
 inlining failed in call to `xxx': redefined extern inline functions are not
 considered for inlining

On Tue, 8 Jan 2008, jakub at gcc dot gnu dot org wrote:

> ------- Comment #6 from jakub at gcc dot gnu dot org  2008-01-08 17:25 -------
> So do I and even am using that patch for quite some time in our gcc packages.

So do I.

> But Mark objected to that:
> http://gcc.gnu.org/ml/gcc-patches/2007-11/msg00589.html
> The current state of things is bad, because with glibc 2.7+ several valid
> programs don't compile.  And this late in stage3 is probably dangerous to play
> with two different bodies in cgraph.

Right, this is something for stage1.

Richard.


-- 


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #8 from hubicka at gcc dot gnu dot org  2008-01-12 13:55 -------
I can definitely commit the patch to silence the (IMO valid) diagnostics. 
However, why programs are using always_inline and extern inline combination at
all?  Just extern inline should be enough.
  /* For GNU C extern inline functions disregard inline limits.  */
  if (DECL_EXTERNAL (fndecl)
      && DECL_DECLARED_INLINE_P (fndecl))
    DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;

So perhaps just modifying glibc headers to not do both would do the trick?

I agree that solving this problem correctly via two functions (not only bodies,
but simply two declarations) is probably bit tricky for stage3. We however have
related PR34609 and PR31529 demonstrating same problem in different context.


Honza


-- 


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

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

[rguenther at suse dot de]

------- Comment #9 from rguenther at suse dot de  2008-01-12 15:13 -------
Subject: Re:  [4.1/4.2/4.3 Regression] Bogus
 inlining failed in call to `xxx': redefined extern inline functions are not
 considered for inlining

On Sat, 12 Jan 2008, hubicka at gcc dot gnu dot org wrote:

> ------- Comment #8 from hubicka at gcc dot gnu dot org  2008-01-12 13:55 -------
> I can definitely commit the patch to silence the (IMO valid) diagnostics. 
> However, why programs are using always_inline and extern inline combination at
> all?  Just extern inline should be enough.
>   /* For GNU C extern inline functions disregard inline limits.  */
>   if (DECL_EXTERNAL (fndecl)
>       && DECL_DECLARED_INLINE_P (fndecl))
>     DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;
> 
> So perhaps just modifying glibc headers to not do both would do the trick?
> 
> I agree that solving this problem correctly via two functions (not only bodies,
> but simply two declarations) is probably bit tricky for stage3. We however have
> related PR34609 and PR31529 demonstrating same problem in different context.

Can you give it a try?  If it looks reasonably safe I would certainly
prefer such a solution.

Richard.


-- 


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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #10 from jsm28 at gcc dot gnu dot org  2008-02-01 16:54 -------
4.2.3 is being released now, changing milestones of open bugs to 4.2.4.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.3                       |4.2.4


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

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

[hubicka at gcc dot gnu dot org]

------- Comment #11 from hubicka at gcc dot gnu dot org  2008-02-13 18:15 -------
I must say that I don't see it that safe: we can't clone the functions because
at the time fronend decide to rewrite the body by new one we are not having
functions gimplified yet.  (well we can clone, but we want to get rid of
non-gimple inlining code too). Keeping the unclonned body around seems
difficult in combination with one declaration rule.  But perhaps it is just my
limited knowledge of C and C++ frontends here..


-- 


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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #12 from jsm28 at gcc dot gnu dot org  2008-05-19 20:23 -------
4.2.4 is being released, changing milestones to 4.2.5.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.2.4                       |4.2.5


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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #13 from jsm28 at gcc dot gnu dot org  2008-07-04 22:51 -------
Closing 4.1 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.1/4.2/4.3/4.4 Regression]|[4.2/4.3/4.4 Regression]
                   |Bogus inlining failed in    |Bogus inlining failed in
                   |call to `xxx': redefined    |call to `xxx': redefined
                   |extern inline functions are |extern inline functions are
                   |not considered for inlining |not considered for inlining


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

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

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2008-11-13 13:55 -------
The reason for using always_inline attribute in glibc headers is that whether
these (tiny) wrappers are inlined or not is a security matter for the program
(if they are inlined, -D_FORTIFY_SOURCE checking is performed, if they are not,
then no checking is done), and that checking shouldn't be affected by how many
functions were already inlined into some function etc.

As this isn't going to be fixed in 4.4 either, could we get the sorry quieted
up?


-- 


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

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

[jsm28 at gcc dot gnu dot org]

------- Comment #15 from jsm28 at gcc dot gnu dot org  2009-03-31 20:12 -------
Closing 4.2 branch.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2/4.3/4.4/4.5 Regression]|[4.3/4.4/4.5 Regression]
                   |Bogus inlining failed in    |Bogus inlining failed in
                   |call to `xxx': redefined    |call to `xxx': redefined
                   |extern inline functions are |extern inline functions are
                   |not considered for inlining |not considered for inlining
   Target Milestone|4.2.5                       |4.3.4


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2009-08-04 12:28 -------
GCC 4.3.4 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.4                       |4.3.5


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2010-01-16 06:52 -------
Note on the trunk it fails at -O1 but not -O2.


-- 


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

[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 dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2010-05-22 18:11 -------
GCC 4.3.5 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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