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

2008-06-16 Thread 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.

templatetypename T
struct B {
struct C {
__attribute__((always_inline)) C(C const c)
{
}
};
void __attribute__((always_inline)) g(C c)
{
}
};

void trigger(Bint b, Bint::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(Bint, Bint::C)':
Cleanup4.ii:8: sorry, unimplemented: inlining failed in call to 'void
BT::g(BT::C) [with T = int]': recursive inlining
Cleanup4.ii:15: sorry, unimplemented: called from here


-- 


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

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

2008-06-11 Thread 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:

templateclass T
class B {
public:
class C {
public:
__attribute__((always_inline)) C(C const c)
{
}
};
void __attribute__((always_inline)) g(C c)
{
}
};

void trigger(Bint b, Bint::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

2007-06-27 Thread 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=gccview=revrev=126054
Log:
2007-06-27  Richard Guenther  [EMAIL PROTECTED]

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

2007-06-27 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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

2007-06-26 Thread 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
movl8(%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
movl8(%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

2007-06-26 Thread Andrew Pinski 

On 26 Jun 2007 21:55:34 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:

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

3.4:

f:
pushl   %ebp
movl%esp, %ebp
movl8(%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
movl8(%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

2007-06-26 Thread 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 -, rguenther at suse dot de
[EMAIL PROTECTED] wrote:
 I have a hard time deciding if 3.4 or 4.1 is better:

 3.4:

 f:
 pushl   %ebp
 movl%esp, %ebp
 movl8(%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
 movl8(%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