[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-11-19 Thread amylaar at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amylaar at gcc dot gnu.org

--- Comment #33 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org 
2011-11-19 11:30:34 UTC ---
There is also the case where no argument has been stored on the stack yet.
That's quite common for ABIs that pass arguments in registers.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-08-15 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #32 from H.J. Lu hjl.tools at gmail dot com 2011-08-15 14:12:04 
UTC ---
Can we check 2 cases:

1. Indirect function call via a register (PR 50074).
2. Non of function arguments are pointers (PR 49179).


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-12 Thread rguenther at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #29 from rguenther at suse dot de rguenther at suse dot de 
2011-07-12 08:35:18 UTC ---
On Tue, 12 Jul 2011, ian at airs dot com wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
 
 Ian Lance Taylor ian at airs dot com changed:
 
What|Removed |Added
 
  CC||ian at airs dot com
 
 --- Comment #27 from Ian Lance Taylor ian at airs dot com 2011-07-12 
 04:37:01 UTC ---
 This patch seems too conservative and it appears that it will cause the
 compiler to miss all tailcalls with pointer arguments.  It only matters if the
 register points to the incoming parameters, which can only  happen in unusual
 cases.  We should be able to determine that reliably.  Janis, did you open a 
 PR
 for the missing optimization?  I didn't see one.

The point is, of course, we have to determine it conservatively correct.
The patch makes sure we do that.

Richard.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-12 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-12 
08:42:40 UTC ---
 This patch seems too conservative and it appears that it will cause the
 compiler to miss all tailcalls with pointer arguments.  It only matters if the
 register points to the incoming parameters, which can only  happen in unusual
 cases.  We should be able to determine that reliably.

This is a bit of an overstatement though, as

extern int foo (int, int *);

int i;

int bar (int a, int b)
{
  int *p = i;
  return foo (a, p);
}

will be caught.  Even this

extern int foo (int, int);

int i;

int bar (int a, int b)
{
  int *p = i;
  return foo (a, *p);
}

will be caught thanks to alias analysis at the Tree level.

As for the reliably, this time it's a little optimistic IMO. :-)  But we can
probably be less conservative with more work.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-12 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #31 from Janis Johnson janis at gcc dot gnu.org 2011-07-12 
15:06:03 UTC ---
I filed PR middle-end/49719 for the sibcall-1.c failure.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-11 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-11 
11:54:01 UTC ---
Fixed.  For the missed tailcall opt please open a separate bugreport.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-11 Thread ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Ian Lance Taylor ian at airs dot com changed:

   What|Removed |Added

 CC||ian at airs dot com

--- Comment #27 from Ian Lance Taylor ian at airs dot com 2011-07-12 04:37:01 
UTC ---
This patch seems too conservative and it appears that it will cause the
compiler to miss all tailcalls with pointer arguments.  It only matters if the
register points to the incoming parameters, which can only  happen in unusual
cases.  We should be able to determine that reliably.  Janis, did you open a PR
for the missing optimization?  I didn't see one.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-11 Thread ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #28 from Ian Lance Taylor ian at airs dot com 2011-07-12 04:54:14 
UTC ---
*** Bug 49709 has been marked as a duplicate of this bug. ***


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-08 Thread hjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #24 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2011-07-08 
13:12:05 UTC ---
Author: hjl
Date: Fri Jul  8 13:12:03 2011
New Revision: 176042

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176042
Log:
Fix PR middle-end/49519.

gcc/

2011-07-08  Kirill Yukhin  kirill.yuk...@intel.com

PR middle-end/49519
* calls.c (mem_overlaps_already_clobbered_arg_p): Additional
check if address is stored in register. If so - give up.
(check_sibcall_argument_overlap_1): Do not perform check of
overlapping when it is call to address.

gcc/tessuite/

2011-07-08  Kirill Yukhin  kirill.yuk...@intel.com

PR middle-end/49519
* g++.dg/torture/pr49519.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr49519.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-08 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Janis Johnson janis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu.org

--- Comment #25 from Janis Johnson janis at gcc dot gnu.org 2011-07-08 
23:36:25 UTC ---
Test gcc.target/arm/sibcall-1.c starts failing with r176042 for
arm-none-linux-gnueabi configured with defaults for arch and cpu.  The failure
can be reproduced with a simple cross cc1.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Target|i686|i?86-*-*
  Component|c++ |middle-end

--- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-06 
10:30:26 UTC ---
The testcase reproduces the problem for me on trunk already with
-m32 -O -foptimize-sibling-calls, so it doesn't seem to be IPA SRA related.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread kirill.yukhin at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #16 from Yukhin Kirill kirill.yukhin at intel dot com 2011-07-06 
10:35:03 UTC ---
Yes.

This is because expander prepares arguments like this:
...
(insn 6 5 7 2 (parallel [
(set (reg:SI 64)
(plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 2.cc:103 -1
 (nil))

(insn 7 6 8 2 (set (reg:SI 65)
(mem/c:SI (plus:SI (reg:SI 64)
(const_int 12 [0xc])) [0 MEM[(int )t + 12]+0 S4 A32]))
2.cc:103 -1
 (nil))

(insn 8 7 9 2 (set (mem:SI (plus:SI (reg/f:SI 53 virtual-incoming-args)
(const_int 12 [0xc])) [0 S4 A32])
(reg:SI 65)) 2.cc:103 -1
 (nil))
...

So, calls.c/mem_overlaps_already_clobbered_arg_p unable to determine, that data
come from stack, so it returns true and enables tailcall.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #17 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-06 
10:37:57 UTC ---
I suspect that the tailcalling code does not expect TER to happen when
expanding the call arguments?  With -fno-tree-ter the issue also isn't
appearant.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-06 
10:49:24 UTC ---
Hm, the argument setup for the tailcall clobbers the incoming stack argument.
And without TER we do not overlap argument setup with the loads from the
incoming stack argument.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread kirill.yukhin at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #19 from Yukhin Kirill kirill.yukhin at intel dot com 2011-07-06 
11:49:34 UTC ---
Created attachment 24701
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
Patch to make tailcall check more conservative

Attached patch adds another check for clobbered stack area.
If address comes from a register - we have no idea about destination address.
That means we must act in conservative way - address possibly overlaps with
stack area of interest.


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread kirill.yukhin at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #20 from Yukhin Kirill kirill.yukhin at intel dot com 2011-07-06 
11:50:51 UTC ---
With patch attached both tescase and 447.dealII passing


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread rguenther at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #21 from rguenther at suse dot de rguenther at suse dot de 
2011-07-06 11:53:56 UTC ---
On Wed, 6 Jul 2011, kirill.yukhin at intel dot com wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
 
 --- Comment #19 from Yukhin Kirill kirill.yukhin at intel dot com 
 2011-07-06 11:49:34 UTC ---
 Created attachment 24701
   -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
 Patch to make tailcall check more conservative
 
 Attached patch adds another check for clobbered stack area.
 If address comes from a register - we have no idea about destination address.
 That means we must act in conservative way - address possibly overlaps with
 stack area of interest.

That looks reasonable.  Can you bootstrap  test this fix and post it to
gcc-patches?


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread kirill.yukhin at intel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

--- Comment #22 from Yukhin Kirill kirill.yukhin at intel dot com 2011-07-06 
11:57:21 UTC ---
(In reply to comment #21)
 On Wed, 6 Jul 2011, kirill.yukhin at intel dot com wrote:
 
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
  
  --- Comment #19 from Yukhin Kirill kirill.yukhin at intel dot com 
  2011-07-06 11:49:34 UTC ---
  Created attachment 24701 [details]
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24701
  Patch to make tailcall check more conservative
  
  Attached patch adds another check for clobbered stack area.
  If address comes from a register - we have no idea about destination 
  address.
  That means we must act in conservative way - address possibly overlaps with
  stack area of interest.
 
 That looks reasonable.  Can you bootstrap  test this fix and post it to
 gcc-patches?

Already in progress :)


[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006

2011-07-06 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519

H.J. Lu hjl.tools at gmail dot com changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2011-07/msg00359.htm
   ||l

--- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2011-07-06 19:37:39 
UTC ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00359.html