[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-27 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #11 from Janis Johnson janis at gcc dot gnu.org 2011-06-27 
18:05:41 UTC ---
I have confirmed that the -Os failures began with r175063 and that the tests
pass for several revision before that and pass for several after, so it's
unlikely to be an intermittent failure.  If it would help I can send dump files
for r175063 and the one just before that.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Janis Johnson janis at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janis at gcc dot gnu.org

--- Comment #5 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 
22:00:07 UTC ---
Starting with r175063, arm-none-linux-gnueabi using default configuration for
arch/cpu/fpu/float-abi gets these failures:

FAIL: gcc.c-torture/execute/920501-7.c execution,  -Os
FAIL: gcc.c-torture/execute/comp-goto-2.c execution,  -Os
FAIL: gcc.dg/torture/stackalign/comp-goto-1.c  -Os  execution test
FAIL: gcc.dg/torture/stackalign/non-local-goto-4.c  -Os  execution test

The failures are only for -Os, not for other optimization levels that Ramana
sees for his configuration.  Let me know if this needs a separate PR.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread eraman at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #6 from Easwaran Raman eraman at google dot com 2011-06-24 
22:19:40 UTC ---
Could you please test if r175384 fixes these failures? Otherwise please run one
of the smaller tests with -fdump-rtl-dse1-all and -fdump-rtl-cse2 (the pass
before DSE) and upload those dumps and I will take a look.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #7 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 
23:01:40 UTC ---
Created attachment 24600
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24600
rtl dump for -Os failure


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #9 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 
23:02:58 UTC ---
I still get the -Os failures (I never had the others) with r175389 and have
attached the requested rtl dumps.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread janis at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #8 from Janis Johnson janis at gcc dot gnu.org 2011-06-24 
23:02:12 UTC ---
Created attachment 24601
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24601
rtl dump for -Os failure


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-24 Thread eraman at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #10 from Easwaran Raman eraman at google dot com 2011-06-24 
23:07:58 UTC ---
(In reply to comment #9)
 I still get the -Os failures (I never had the others) with r175389 and have
 attached the requested rtl dumps.

This doesn't look like a DSE related bug to me. The RTL dump shows that no
store has been deleted by DSE in any of the functions.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-20 Thread ramana at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Ramana Radhakrishnan ramana at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.06.20 14:52:06
 CC||eraman at google dot com
 Ever Confirmed|0   |1


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-18 Thread ramana at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org 2011-06-18 
08:37:06 UTC ---
(In reply to comment #3)
  I haven't looked at in great detail yet to analyse what causes this problem 
  but
  it appears to have appeared in the last week or so.
 
 Maybe r175063 (significant dse.c change).

It does appear to be that revision triggering this change. 
The problem essentially here is that the backend generates 


(insn/f 36 35 37 2 (set (reg/f:SI 11 fp)
(plus:SI (reg/f:SI 13 sp)
(const_int 96 [0x60])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
 (nil))

(insn/f 37 36 38 2 (set (reg/f:SI 13 sp)
(plus:SI (reg/f:SI 13 sp)
(const_int -28 [0xffe4])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
 (nil))

(insn 38 37 39 2 (set (mem:BLK (scratch) [0 A8])
(unspec:BLK [
(reg/f:SI 13 sp)
(reg/f:SI 11 fp)
] UNSPEC_PRLG_STK))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
-1
 (nil))

(note 39 38 5 2 NOTE_INSN_PROLOGUE_END)

(note 5 39 8 2 NOTE_INSN_FUNCTION_BEG)

(note 8 5 9 2 NOTE_INSN_DELETED)

(insn 9 8 2 2 (set (reg:SI 12 ip)
(plus:SI (reg/f:SI 11 fp)
(const_int -112 [0xff90])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
4 {*arm_addsi3}
 (nil))

(insn 2 9 33 2 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -120 [0xff88])) [6 %sfp+-20 S4 A32])
(reg:SI 0 r0 [ a ]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
 (nil))

(insn 33 2 3 2 (set (reg:SI 3 r3)
(plus:SI (reg/f:SI 11 fp)
(const_int -100 [0xff9c])))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
4 {*arm_addsi3}
 (nil))

(insn 3 33 4 2 (set (mem/s/f/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -112 [0xff90])) [5
FRAME.0.__nl_goto_buf+0 S4 A32])
(reg:SI 3 r3))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
 (nil))

(insn 4 3 11 2 (set (mem/s/f/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -108 [0xff94])) [5
FRAME.0.__nl_goto_buf+4 S4 A32])
(reg/f:SI 13 sp))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:11
632 {*arm_movsi_vfp}
 (nil))



but the corresponding load into r0 is from a different offset but the alias
sets appear to be correct. 


(insn 24 16 30 3 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -20 [0xffec])) [6 %sfp+-20 S4 A32]))
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:26
632 {*arm_movsi_vfp}
 (nil))



cheers
Ramana


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-17 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot
   ||gnu.org

--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-17 
16:51:41 UTC ---
 NORETURN attribute marked to it but there's no reason why this should be 
 marked
 as NORETURN - surely there is a flow of control that allows control to go out
 of the function. 
 
 
 x(a)
 {
   __label__ xlab;
   void y(a)
 {
   void *x = llab;
   if (a==-1)
  goto *x;
   if (a==0)
  goto xlab;
 llab:
   y (a-1);
 }
   y (a);
  xlab:;
   return a;
 }

Yes, but this isn't a return, this is a non-local goto so NORETURN is correct.


[Bug tree-optimization/49452] comp-goto-2.c regresses in testing

2011-06-17 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452

--- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-06-17 
16:55:48 UTC ---
 I haven't looked at in great detail yet to analyse what causes this problem 
 but
 it appears to have appeared in the last week or so.

Maybe r175063 (significant dse.c change).