[Bug c++/36631] New: [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[Bug c++/36631] New: [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[josep dot m dot perez at bsc dot es]

The following code generates a recursive inlining error in 4.3.[01] while it
did not in 4.[12]. Somehow, the bug requires having both always_inline
attributes.


template<typename T>
struct B {
        struct C {
                __attribute__((always_inline)) C(C const &c)
                {
                }
        };
        void __attribute__((always_inline)) g(C c)
        {
        }
};

void trigger(B<int> b, B<int>::C c)
{
        b.g(c);
}


Cleanup4.ii: In function 'void trigger(B<int>, B<int>::C)':
Cleanup4.ii:8: sorry, unimplemented: inlining failed in call to 'void
B<T>::g(B<T>::C) [with T = int]': recursive inlining
Cleanup4.ii:15: sorry, unimplemented: called from here


-- 
           Summary: [4.3 Regression] attribute always_inline  ->  sorry,
                    unimplemented: recursive inlining
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: josep dot m dot perez at bsc dot es
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.3 Regression] attribute  |[4.3/4.4 Regression]
                   |always_inline  ->  sorry,   |attribute always_inline  ->
                   |unimplemented: recursive    |sorry, unimplemented:
                   |inlining                    |recursive inlining
   Target Milestone|---                         |4.3.2


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2008-07-10 14:23 -------
Confirmed.  Honza, can you have a look here?


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|c++                         |tree-optimization
     Ever Confirmed|0                           |1
      Known to fail|                            |4.3.1
      Known to work|                            |4.2.4
           Priority|P3                          |P2
   Last reconfirmed|0000-00-00 00:00:00         |2008-07-10 14:23:16
               date|                            |


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[hubicka at gcc dot gnu dot org]

------- Comment #2 from hubicka at gcc dot gnu dot org  2008-07-31 14:44 -------
Richard, there is one problem that is "yours".  We conclude that call is
uninlinable due to type missmatch.  This should not happen on C++.
This gets misdiagnozed as originally recursive inlning was only reason why
inlining of always_inline could've failed on one specific call but not other. 
Now we have mismatches and the function specific stuff.


-- 


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2008-08-07 15:25 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-07-10 14:23:16         |2008-08-07 15:25:00
               date|                            |


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jsm28 at gcc dot gnu dot org]

------- Comment #4 from jsm28 at gcc dot gnu dot org  2008-08-27 22:04 -------
4.3.2 is released, changing milestones to 4.3.3.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.3.2                       |4.3.3


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

[Bug tree-optimization/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2008-09-15 14:26 -------
This looks like a frontend bug to me.  For B::g we record in the DECL_ARGUMENTS

(gdb) call debug_tree (p)
 <parm_decl 0x7fae5daa2f30 c
    type <record_type 0x7fae5d15da80 C addressable needs-constructing type_1
type_5 BLK

with DECL_ARG_TYPE (p) being

 <record_type 0x7fae5d15da80 C addressable needs-constructing type_1 type_5 BLK
    size <integer_cst 0x7fae5da9c7b0 type <integer_type 0x7fae5daaf0c0
bit_size_type> constant invariant 8>

but we pass it a reference in trigger():

(gdb) call debug_tree (*$1)
 <addr_expr 0x7fae5d15f580
    type <reference_type 0x7fae5d163540
        type <record_type 0x7fae5d15da80 C addressable needs-constructing
type_1 type_5 BLK

like so:

(gdb) call debug_generic_expr (*expr_p)
g (&b, &TARGET_EXPR <D.2065, <<< Unknown tree: aggr_init_expr
  5
  __comp_ctor 
  D.2065
  0B
  (const struct C &) (const struct C *) (struct C *) c >>>
>)


which leads to (rightfully) CALL_CANNOT_INLINE_P set.  The TYPE_ARG_TYPES
also require a record for the arguments.


So either the function call is wrong or DECL_ARG_TYPE and TYPE_ARG_TYPES
are not correct.  The offending frontend code doing this is
convert_for_arg_passing which has

  /* Pass classes with copy ctors by invisible reference.  */
  else if (TREE_ADDRESSABLE (type))
    val = build1 (ADDR_EXPR, build_reference_type (type), val);

but it doesn't communicate this to the middle-end.

Jason, can you shed some light on when/if/why not C++ is setting
DECL_ARG_TYPE to what?  Thanks.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu dot org
         AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2008-09-15 14:36 -------
Ok, during gimplification of B::g its function declaration _does_ have proper
reference-typed arguments.  So only during gimplification of trigger () the
function-declaration used for the call to B::g is still "wrong" - it gets
"fixed" later.


-- 


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2008-10-21 12:15 -------
Is there a reason why we have to set
CALL_CANNOT_INLINE_P/gimple_call_cannot_inline already during gimplification?
If we defer setting it till say to lower_stmt, then by that time all the
fndecls will be surely genericized and it will be still before anything will
look at
gimple_call_cannot_inline (ipa-inline.c, {,re}build_cgraph_edges, cfgexpand).


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dodji at gcc dot gnu dot org


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2008-11-04 16:03 -------
Actually, looking at this some more, the problem is just that g has a wrong
DECL_ARG_TYPE.  When instantiate_class_template is called on B, it instantiates
g; class C is returned by lookup_template_class, but not yet a complete type,
so it doesn't have TYPE_HAS_INIT_REF set, nor TYPE_HAS_COMPLEX_INIT_REF, nor
TREE_ADDRESSABLE.  Then tsubst_decl <case PARM_DECL>:
            if (!DECL_TEMPLATE_PARM_P (r))
              DECL_ARG_TYPE (r) = type_passed_as (type);
is called, but the RECORD_TYPE C is still incomplete at this point, so
type_passed_as, seeing no TREE_ADDRESSABLE being set on type, returns type
itself.  Afterwards when require_complete_types_for_parms is called on
trigger's
parameters, instantiate_class_template is called on C and all the above
mentioned 3 bits are set.  But nothing goes back to fix up DECL_ARG_TYPE, at
least not until instantiate_pending_templates eventually calls
require_complete_types_for_parms on g's params.  But that is already way after
trigger has been gimplified.  So I believe we need to update DECL_ARG_TYPE
(parm)
from type_passed_as (TREE_TYPE (parm)) for calls a function is making, but am
not sure where would that be best done.  In genericization?


-- 


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2008-11-04 16:43 -------
Created an attachment (id=16624)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16624&action=view)
gcc44-pr36631.patch

Quite ugly fix, Jason, do you have better ideas how to fix this?


-- 


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

[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2008-11-20 01:48 -------
Subject: Bug 36631

Author: jakub
Date: Thu Nov 20 01:47:10 2008
New Revision: 142033

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142033
Log:
        PR c++/36631
        * gimplify.c (gimplify_call_expr): Defer most of the cannot inline
        checking until GIMPLE lowering.
        * gimple-low.c (check_call_args): New function.
        (lower_stmt) <case GIMPLE_CALL>: Call it.

        * g++.dg/template/call5.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/template/call5.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/gimple-low.c
    trunk/gcc/gimplify.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug c++/36631] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[jakub at gcc dot gnu dot org]

-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
      Known to work|4.2.4                       |4.2.4 4.4.0
   Last reconfirmed|2008-08-07 15:25:00         |2008-11-20 01:51:15
               date|                            |
            Summary|[4.3/4.4 Regression]        |[4.3 Regression] attribute
                   |attribute always_inline  -> |always_inline  ->  sorry,
                   |sorry, unimplemented:       |unimplemented: recursive
                   |recursive inlining          |inlining


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

[Bug c++/36631] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2009-01-24 10:20 -------
GCC 4.3.3 is being released, adjusting target milestone.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug c++/36631] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-08-04 12:29 -------
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=36631

[Bug c++/36631] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-05-22 18:12 -------
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=36631