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

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

[wouter dot vermaelen at scarlet dot be]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]

> cat bug.ii
__attribute__((always_inline)) void f1() {}
__attribute__((always_inline)) void f2(char) {}
void f3() { f1(); f2(0); }

> g++ bug.ii
bug.ii: In function ‘void f3()’:
bug.ii:2: sorry, unimplemented: inlining failed in call to ‘void f2(char)’:
recursive inlining
bug.ii:3: sorry, unimplemented: called from here


-- 
           Summary: 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: wouter dot vermaelen at scarlet dot be


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

[Bug c++/32492] [4.3 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  2007-06-26 10:32 -------
The types do not match at gimplification time:

(gdb) call debug_tree (x)
 <integer_type 0x2b07ce1fb540 int public SI
    size <integer_cst 0x2b07ce1e8a50 type <integer_type 0x2b07ce1fb0c0
bit_size_type> constant invariant 32>
    unit size <integer_cst 0x2b07ce1e86c0 type <integer_type 0x2b07ce1fb000
long unsigned int> constant invariant 4>
    align 32 symtab 0 alias set -1 canonical type 0x2b07ce1fb540 precision 32
min <integer_cst 0x2b07ce1e89c0 -2147483648> max <integer_cst 0x2b07ce1e89f0
2147483647>
    pointer_to_this <pointer_type 0x2b07ce20d9c0>>
(gdb) call debug_tree (y)
 <integer_type 0x2b07ce1fb300 char public string-flag QI
    size <integer_cst 0x2b07ce1e87b0 type <integer_type 0x2b07ce1fb0c0
bit_size_type> constant invariant 8>
    unit size <integer_cst 0x2b07ce1e87e0 type <integer_type 0x2b07ce1fb000
long unsigned int> constant invariant 1>
    align 8 symtab 0 alias set -1 canonical type 0x2b07ce1fb300 precision 8 min
<integer_cst 0x2b07ce1e8750 -128> max <integer_cst 0x2b07ce1e88a0 127>
    pointer_to_this <pointer_type 0x2b07ce211cc0>>

TYPE_ARG_TYPES says we want a char, but the call expression has an int.  I
would say this is a C++ frontend bug?  Or is this somehow expected and we
need to "deal" with this mismatch?

Mark?  Jason?  This works with the C frontend.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, mmitchel at gcc dot gnu
                   |                            |dot org, jason at gcc dot
                   |                            |gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Keywords|                            |rejects-valid
   Last reconfirmed|0000-00-00 00:00:00         |2007-06-26 10:32:10
               date|                            |
            Summary|attribute always_inline  -> |[4.3 Regression] attribute
                   |sorry, unimplemented:       |always_inline  ->  sorry,
                   |recursive inlining          |unimplemented: recursive
                   |                            |inlining


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

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

[Daniel Jacobowitz]

Can we get a better error message than "recursive inlining", btw? :-)

-- 
Daniel Jacobowitz
CodeSourcery

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

[mark at codesourcery dot com]

------- Comment #2 from mark at codesourcery dot com  2007-06-26 12:14 -------
Subject: Re:  [4.3 Regression] attribute always_inline  ->
  sorry, unimplemented: recursive inlining

rguenth at gcc dot gnu dot org wrote:

> TYPE_ARG_TYPES says we want a char, but the call expression has an int.  I
> would say this is a C++ frontend bug?  Or is this somehow expected and we
> need to "deal" with this mismatch?

This is probably something that used to be considered OK, but is now
considered a C++ front-end bug.  For avoidance of doubt, I think that
the C++ front end should be changed so that the argument has type "char".


-- 


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

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.3.0


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2007-06-26 14:39 -------
The C front-end has the same "wrong type".  ./cc1 -funit-at-a-time t.c gives:
t33.c: In function 'f3':
t33.c:2: sorry, unimplemented: inlining failed in call to 'f2': recursive
inlining
t33.c:3: sorry, unimplemented: called from here


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |c


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2007-06-26 14:51 -------
Related to PR 15484, at least that PR is the underlying cause.
For the C front-end the promoting happens in convert_arguments, c-typeck.c.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |15484


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-26 14:53 -------
I am going to change the component as middle-end while someone figures out if
we want to promote in the front-ends or later on.  I say we want to promote in
front-ends rather than later on because we get more information about the how
the arguments would look like (and we might lose some info otherwise).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker
          Component|c                           |middle-end


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenther at suse dot de]

------- Comment #6 from rguenther at suse dot de  2007-06-26 15:03 -------
Subject: Re:  [4.3 Regression] attribute always_inline
  ->  sorry, unimplemented: recursive inlining

On Tue, 26 Jun 2007, pinskia at gcc dot gnu dot org wrote:

> ------- Comment #5 from pinskia at gcc dot gnu dot org  2007-06-26 14:53 -------
> I am going to change the component as middle-end while someone figures out if
> we want to promote in the front-ends or later on.  I say we want to promote in
> front-ends rather than later on because we get more information about the how
> the arguments would look like (and we might lose some info otherwise).

Sure, but then the frontends should also promote the functions type
signatures.  How should the middle-end decide what type is correct?

Richard.


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[drow at gcc dot gnu dot org]

------- Comment #7 from drow at gcc dot gnu dot org  2007-06-26 16:29 -------
Can we fix the error message, while we're here?  Obviously it wasn't recursive
inlining.


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2007-06-26 20:45 -------
So, without touching all the frontends we can try to lower constraints checked
at gimplification time to what is actually needed to avoid the ICE during
inlining.  Which is to make sure that the actual parameter is convertible to
the type of the parameter declaration using a NOP_EXPR conversion.  Which the
following (nearly) implements:

@@ -2134,15 +2134,17 @@ gimplify_call_expr (tree *expr_p, tree *

   /* Verify if the type of the argument matches that of the function
      declaration.  If we cannot verify this or there is a mismatch,
-     mark the call expression so it doesn't get inlined later.  */
+     mark the call expression so it doesn't get inlined later.
+     This is needed to make sure we can convert the call expression
+     arguments to the inlined parameter declarations using a NOP_EXPR.  */
   if (parms)
     {
       for (i = 0, p = parms; i < nargs; i++, p = TREE_CHAIN (p))
        if (!p
            || TREE_VALUE (p) == error_mark_node
            || CALL_EXPR_ARG (*expr_p, i) == error_mark_node
-           || !lang_hooks.types_compatible_p
-                (TREE_TYPE (CALL_EXPR_ARG (*expr_p, i)), TREE_VALUE (p)))
+           || TREE_CODE (TREE_TYPE (CALL_EXPR_ARG (*expr_p, i)))
+              != TREE_CODE (TREE_VALUE (p)))
          {
            CALL_CANNOT_INLINE_P (*expr_p) = 1;
            break;
@@ -2155,8 +2157,8 @@ gimplify_call_expr (tree *expr_p, tree *
        if (!p
            || p == error_mark_node
            || CALL_EXPR_ARG (*expr_p, i) == error_mark_node
-           || !lang_hooks.types_compatible_p
-                (TREE_TYPE (CALL_EXPR_ARG (*expr_p, i)), TREE_TYPE (p)))
+           || TREE_CODE (TREE_TYPE (CALL_EXPR_ARG (*expr_p, i)))
+              != TREE_CODE (TREE_TYPE (p)))
          {
            CALL_CANNOT_INLINE_P (*expr_p) = 1;
            break;

I'll come up with a predicate to compute this in a more precise way, like
fold_convertible_p.  I also know Honza is working on a different approach.


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2007-06-26 21:07 -------
I'm testing a patch.


-- 

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|2007-06-26 10:32:10         |2007-06-26 21:07:02
               date|                            |


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2007-06-26 21:24 -------
And I think we should address PR15484 and not do type promotion until RTL
expansion.


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2007-06-26 21:33 -------
I can find a testcase, if we change where we generate the promotion at the RTL
expansion time, worse code.
Simple testcase:

int f(int b, char a)
{
  if (b)
    a = 1;
  g(a);
}

You can see the difference by looking 3.4 vs 4.2's code generation :).


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenther at suse dot de]

------- Comment #12 from rguenther at suse dot de  2007-06-26 21:55 -------
Subject: Re:  [4.3 Regression] attribute always_inline
  ->  sorry, unimplemented: recursive inlining

On Tue, 26 Jun 2007, pinskia at gcc dot gnu dot org wrote:

> I can find a testcase, if we change where we generate the promotion at the RTL
> expansion time, worse code.
> Simple testcase:
> 
> int f(int b, char a)
> {
>   if (b)
>     a = 1;
>   g(a);
> }
> 
> You can see the difference by looking 3.4 vs 4.2's code generation :).

I have a hard time deciding if 3.4 or 4.1 is better:

3.4:

f:
        pushl   %ebp
        movl    %esp, %ebp
        movl    8(%ebp), %edx
        movzbl  12(%ebp), %eax
        testl   %edx, %edx
        je      .L2
        movb    $1, %al
.L2:
        movsbl  %al,%eax
        movl    %eax, 8(%ebp)
        popl    %ebp
        jmp     g

4.1 (same as 4.2):

f:
        pushl   %ebp
        movl    $1, %edx
        movl    %esp, %ebp
        movl    8(%ebp), %ecx
        movzbl  12(%ebp), %eax
        testl   %ecx, %ecx
        je      .L7
        movl    %edx, 8(%ebp)
        popl    %ebp
        jmp     g
        .p2align 4,,7
.L7:
        movsbl  %al,%edx
        movl    %edx, 8(%ebp)
        popl    %ebp
        jmp     g


-- 


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

Re: [Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[Andrew Pinski]

On 26 Jun 2007 21:55:34 -0000, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:
> I have a hard time deciding if 3.4 or 4.1 is better:
>
> 3.4:
>
> f:
>         pushl   %ebp
>         movl    %esp, %ebp
>         movl    8(%ebp), %edx
>         movzbl  12(%ebp), %eax
>         testl   %edx, %edx
>         je      .L2
>         movb    $1, %al
> .L2:
>         movsbl  %al,%eax
<---- unconditional movsbl.
>         movl    %eax, 8(%ebp)
>         popl    %ebp
>         jmp     g
>
> 4.1 (same as 4.2):
>
> f:
>         pushl   %ebp
>         movl    $1, %edx
>         movl    %esp, %ebp
>         movl    8(%ebp), %ecx
>         movzbl  12(%ebp), %eax
>         testl   %ecx, %ecx
>         je      .L7
>         movl    %edx, 8(%ebp)
>         popl    %ebp
>         jmp     g
>         .p2align 4,,7
> .L7:
>         movsbl  %al,%edx
// <--- condtional movsbl
>         movl    %edx, 8(%ebp)
>         popl    %ebp
>         jmp     g

It is easier to see the diference between 3.4 and the trunk where we
don't duplicate the tail call to g.

Thanks,
Andrew Pinski

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[pinskia at gmail dot com]

------- Comment #13 from pinskia at gmail dot com  2007-06-26 21:59 -------
Subject: Re:  [4.3 Regression] attribute always_inline -> sorry, unimplemented:
recursive inlining

On 26 Jun 2007 21:55:34 -0000, rguenther at suse dot de
<gcc-bugzilla@gcc.gnu.org> wrote:
> I have a hard time deciding if 3.4 or 4.1 is better:
>
> 3.4:
>
> f:
>         pushl   %ebp
>         movl    %esp, %ebp
>         movl    8(%ebp), %edx
>         movzbl  12(%ebp), %eax
>         testl   %edx, %edx
>         je      .L2
>         movb    $1, %al
> .L2:
>         movsbl  %al,%eax
<---- unconditional movsbl.
>         movl    %eax, 8(%ebp)
>         popl    %ebp
>         jmp     g
>
> 4.1 (same as 4.2):
>
> f:
>         pushl   %ebp
>         movl    $1, %edx
>         movl    %esp, %ebp
>         movl    8(%ebp), %ecx
>         movzbl  12(%ebp), %eax
>         testl   %ecx, %ecx
>         je      .L7
>         movl    %edx, 8(%ebp)
>         popl    %ebp
>         jmp     g
>         .p2align 4,,7
> .L7:
>         movsbl  %al,%edx
// <--- condtional movsbl
>         movl    %edx, 8(%ebp)
>         popl    %ebp
>         jmp     g

It is easier to see the diference between 3.4 and the trunk where we
don't duplicate the tail call to g.

Thanks,
Andrew Pinski


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #14 from rguenth at gcc dot gnu dot org  2007-06-27 14:01 -------
Subject: Bug 32492

Author: rguenth
Date: Wed Jun 27 14:01:27 2007
New Revision: 126054

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126054
Log:
2007-06-27  Richard Guenther  <rguenther@suse.de>

        PR middle-end/32492
        * tree.h (fold_convertible_p): Declare.
        * fold-const.c (fold_convertible_p): New function.
        * gimplify.c (gimplify_call_expr): Use fold_convertible_p
        instead of lang_hooks.types_compatible_p.

        * gcc.dg/inline-22.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/inline-22.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/fold-const.c
    trunk/gcc/gimplify.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree.h


-- 


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2007-06-27 15:05 -------
Fixed.  Sort of.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[josep dot m dot perez at bsc dot es]

------- Comment #16 from josep dot m dot perez at bsc dot es  2008-06-11 10:06 -------
The following code still triggers this bug in 4.3 but not in 4.2:

template<class T>
class B {
        public:
                class C {
                        public:
                                __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);
}


I'm using g++-4.3 (Debian 4.3.1-1) 4.3.1 on x86.


-- 

josep dot m dot perez at bsc dot es changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |josep dot m dot perez at bsc
                   |                            |dot es


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

[Bug middle-end/32492] [4.3 Regression] attribute always_inline -> sorry, unimplemented: recursive inlining

[josep dot m dot perez at bsc dot es]

------- Comment #17 from josep dot m dot perez at bsc dot es  2008-06-16 09:23 -------
I've reproduced the same problem with official GCC 4.3.1 on Linux amd64.

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);
}


Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/opt/gcc-4.3.1
Thread model: posix
gcc version 4.3.1 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mtune=generic'
 /opt/gcc-4.3.1/libexec/gcc/x86_64-unknown-linux-gnu/4.3.1/cc1plus
-fpreprocessed Cleanup4.ii -quiet -dumpbase Cleanup4.ii -mtune=generic -auxbase
Cleanup4 -version -o /tmp/ccJPmqDW.s
GNU C++ (GCC) version 4.3.1 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.3.1, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128607
Compiler executable checksum: 24d9f1589345aaa01dede2a12dd4f7be
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


-- 


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