* [Bug tree-optimization/49452] New testsuite failures with arm-linux-gnueabi comp-goto failing with
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
@ 2011-06-17 12:02 ` ramana at gcc dot gnu.org
2011-06-17 16:52 ` [Bug tree-optimization/49452] comp-goto-2.c regresses in testing ebotcazou at gcc dot gnu.org
` (26 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana at gcc dot gnu.org @ 2011-06-17 12:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #1 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-06-17 12:02:10 UTC ---
One of the differences I must say I noticed is that at O2 - the call to y has a
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;
}
(call_insn/c/i 11 10 12 3 (parallel [
(call (mem:SI (symbol_ref:SI ("y.2104") [flags 0x3] <function_decl
0xb7499400 y>) [0 y S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/home/ramrad01/sources/fsf/trunk/gcc/testsuite/gcc.c-torture/execute/comp-goto-2.c:23
-1
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
(nil))))
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
2011-06-17 12:02 ` [Bug tree-optimization/49452] " ramana at gcc dot gnu.org
@ 2011-06-17 16:52 ` ebotcazou at gcc dot gnu.org
2011-06-17 16:56 ` ebotcazou at gcc dot gnu.org
` (25 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-06-17 16:52 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
2011-06-17 12:02 ` [Bug tree-optimization/49452] " ramana at gcc dot gnu.org
2011-06-17 16:52 ` [Bug tree-optimization/49452] comp-goto-2.c regresses in testing ebotcazou at gcc dot gnu.org
@ 2011-06-17 16:56 ` ebotcazou at gcc dot gnu.org
2011-06-18 8:38 ` ramana at gcc dot gnu.org
` (24 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-06-17 16:56 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (2 preceding siblings ...)
2011-06-17 16:56 ` ebotcazou at gcc dot gnu.org
@ 2011-06-18 8:38 ` ramana at gcc dot gnu.org
2011-06-20 14:53 ` ramana at gcc dot gnu.org
` (23 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana at gcc dot gnu.org @ 2011-06-18 8:38 UTC (permalink / raw)
To: gcc-bugs
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 [0xffffffffffffffe4])))
/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 [0xffffffffffffff90])))
/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 [0xffffffffffffff88])) [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 [0xffffffffffffff9c])))
/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 [0xffffffffffffff90])) [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 [0xffffffffffffff94])) [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 [0xffffffffffffffec])) [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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (3 preceding siblings ...)
2011-06-18 8:38 ` ramana at gcc dot gnu.org
@ 2011-06-20 14:53 ` ramana at gcc dot gnu.org
2011-06-24 22:01 ` janis at gcc dot gnu.org
` (22 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana at gcc dot gnu.org @ 2011-06-20 14:53 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (4 preceding siblings ...)
2011-06-20 14:53 ` ramana at gcc dot gnu.org
@ 2011-06-24 22:01 ` janis at gcc dot gnu.org
2011-06-24 22:20 ` eraman at google dot com
` (21 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janis at gcc dot gnu.org @ 2011-06-24 22:01 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (5 preceding siblings ...)
2011-06-24 22:01 ` janis at gcc dot gnu.org
@ 2011-06-24 22:20 ` eraman at google dot com
2011-06-24 23:03 ` janis at gcc dot gnu.org
` (20 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: eraman at google dot com @ 2011-06-24 22:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (6 preceding siblings ...)
2011-06-24 22:20 ` eraman at google dot com
@ 2011-06-24 23:03 ` janis at gcc dot gnu.org
2011-06-24 23:05 ` janis at gcc dot gnu.org
` (19 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janis at gcc dot gnu.org @ 2011-06-24 23:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (7 preceding siblings ...)
2011-06-24 23:03 ` janis at gcc dot gnu.org
@ 2011-06-24 23:05 ` janis at gcc dot gnu.org
2011-06-24 23:06 ` janis at gcc dot gnu.org
` (18 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janis at gcc dot gnu.org @ 2011-06-24 23:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (8 preceding siblings ...)
2011-06-24 23:05 ` janis at gcc dot gnu.org
@ 2011-06-24 23:06 ` janis at gcc dot gnu.org
2011-06-24 23:09 ` eraman at google dot com
` (17 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janis at gcc dot gnu.org @ 2011-06-24 23:06 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (9 preceding siblings ...)
2011-06-24 23:06 ` janis at gcc dot gnu.org
@ 2011-06-24 23:09 ` eraman at google dot com
2011-06-27 18:06 ` janis at gcc dot gnu.org
` (16 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: eraman at google dot com @ 2011-06-24 23:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (10 preceding siblings ...)
2011-06-24 23:09 ` eraman at google dot com
@ 2011-06-27 18:06 ` janis at gcc dot gnu.org
2011-07-14 8:46 ` [Bug tree-optimization/49452] [4.7 regression] " ebotcazou at gcc dot gnu.org
` (15 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: janis at gcc dot gnu.org @ 2011-06-27 18:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (11 preceding siblings ...)
2011-06-27 18:06 ` janis at gcc dot gnu.org
@ 2011-07-14 8:46 ` ebotcazou at gcc dot gnu.org
2011-07-14 17:17 ` eraman at google dot com
` (14 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-07-14 8:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Version|unknown |4.7.0
Target Milestone|--- |4.7.0
Summary|comp-goto-2.c regresses in |[4.7 regression]
|testing |comp-goto-2.c regresses in
| |testing
Severity|normal |major
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (12 preceding siblings ...)
2011-07-14 8:46 ` [Bug tree-optimization/49452] [4.7 regression] " ebotcazou at gcc dot gnu.org
@ 2011-07-14 17:17 ` eraman at google dot com
2011-07-14 22:11 ` eraman at google dot com
` (13 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: eraman at google dot com @ 2011-07-14 17:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #12 from Easwaran Raman <eraman at google dot com> 2011-07-14 17:16:06 UTC ---
(In reply to comment #11)
> 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.
It is possible that the second DSE invocation deletes a necessary store. My
understanding was that it only acts on spilled stores and all my changes are in
the _nospill version, but that seems not to be the case. Could you send me all
the RTL dumps with and without this patch as a tar file? That will be very
useful in narrowing it down.
Thanks,
Easwaran
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (13 preceding siblings ...)
2011-07-14 17:17 ` eraman at google dot com
@ 2011-07-14 22:11 ` eraman at google dot com
2011-07-15 6:26 ` ebotcazou at gcc dot gnu.org
` (12 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: eraman at google dot com @ 2011-07-14 22:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #13 from Easwaran Raman <eraman at google dot com> 2011-07-14 22:10:16 UTC ---
I looked at the dumps for 920501-7.c and second invocation of DSE removes a
necessary store. The relevant dump for function x from
920501-7.c.198r.pro_and_epilogue is below:
(insn 2 58 53 2 (set (mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32])
(reg:SI 0 r0 [ a ]))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:12
176 {*arm_movsi_insn}
(nil))
...
(call_insn/c/i 11 9 12 2 (parallel [
(call (mem:SI (symbol_ref:SI ("y.1271") [flags 0x3] <function_decl
0x5578cb80 y>) [0 y S4 A32])
(const_int 0 [0]))
(use (const_int 0 [0]))
(clobber (reg:SI 14 lr))
])
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:20
242 {*call_symbol}
(expr_list:REG_NORETURN (const_int 0 [0])
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:REG_DEP_TRUE (use (reg:SI 0 r0))
(expr_list:REG_DEP_TRUE (use (reg:SI 12 ip))
(nil))))
...
(insn 24 18 30 3 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
/scratch/janisjo/arm-linux-fsf/src/gcc-mainline/gcc/testsuite/gcc.reghunt/920501-7.c:23
176 {*arm_movsi_insn}
(nil))
Instruction 2 and 24 refer to the same location, but have different offset
relative to FP because the call to y changes FP. DSE doesn't (and can not, if
it is intra-procedural) know that they both refer to the same location and
hence thinks insn 2 is dead.
It seems to me this (FP having different value after the call) can only happen
at postreload. It seems to me that setting wild_read (not just
non_frame_wild_read) on all calls after postreload will fix this problem.
What's the best way to do that? Will checking for clear_alias_sets != NULL
work?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (14 preceding siblings ...)
2011-07-14 22:11 ` eraman at google dot com
@ 2011-07-15 6:26 ` ebotcazou at gcc dot gnu.org
2011-07-16 21:19 ` ebotcazou at gcc dot gnu.org
` (11 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-07-15 6:26 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-15 06:26:17 UTC ---
> Instruction 2 and 24 refer to the same location, but have different offset
> relative to FP because the call to y changes FP. DSE doesn't (and can not, if
> it is intra-procedural) know that they both refer to the same location and
> hence thinks insn 2 is dead.
>
> It seems to me this (FP having different value after the call) can only happen
> at postreload.
Hum, this shouldn't happen at all I think. This looks like a latent bug in the
implementation of non-local gotos then.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (15 preceding siblings ...)
2011-07-15 6:26 ` ebotcazou at gcc dot gnu.org
@ 2011-07-16 21:19 ` ebotcazou at gcc dot gnu.org
2011-07-18 16:33 ` ramana at gcc dot gnu.org
` (10 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-07-16 21:19 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #15 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-16 21:18:39 UTC ---
The machine-dependent reorg pass does something unexpected:
(insn 30 18 14 3 (set (reg/f:SI 11 fp)
(plus:SI (reg/f:SI 11 fp)
(const_int 36 [0x24]))) 4 {*arm_addsi3}
(nil))
(insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
(nil))
(insn 16 14 24 3 (unspec_volatile [
(const_int 0 [0])
] VUNSPEC_BLOCKAGE) 252 {blockage}
(nil))
(insn 24 16 27 3 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
(nil))
is reordered into:
(insn 14 18 16 (use (reg/f:SI 11 fp)) -1
(nil))
(insn 16 14 24 (unspec_volatile [
(const_int 0 [0])
] VUNSPEC_BLOCKAGE) 252 {blockage}
(nil))
(insn 24 16 30 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
(nil))
(insn 30 24 27 (set (reg/f:SI 11 fp)
(plus:SI (reg/f:SI 11 fp)
(const_int 36 [0x24]))) 4 {*arm_addsi3}
(nil))
despite the blockage.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (16 preceding siblings ...)
2011-07-16 21:19 ` ebotcazou at gcc dot gnu.org
@ 2011-07-18 16:33 ` ramana at gcc dot gnu.org
2011-07-18 16:36 ` ramana at gcc dot gnu.org
` (9 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana at gcc dot gnu.org @ 2011-07-18 16:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #16 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-18 16:31:12 UTC ---
(In reply to comment #15)
> The machine-dependent reorg pass does something unexpected:
>
> (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 3 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> is reordered into:
>
> (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 30 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> (insn 30 24 27 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> despite the blockage.
Hmmm I'm not sure I see this - what's the configure and arch. specific flags
you used just in case ?
cheers
Ramana
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (17 preceding siblings ...)
2011-07-18 16:33 ` ramana at gcc dot gnu.org
@ 2011-07-18 16:36 ` ramana at gcc dot gnu.org
2011-07-18 17:59 ` ebotcazou at gcc dot gnu.org
` (8 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana at gcc dot gnu.org @ 2011-07-18 16:36 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #17 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2011-07-18 16:35:22 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > The machine-dependent reorg pass does something unexpected:
> >
> > (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> > (plus:SI (reg/f:SI 11 fp)
> > (const_int 36 [0x24]))) 4 {*arm_addsi3}
> > (nil))
> >
> > (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> > (nil))
> >
> > (insn 16 14 24 3 (unspec_volatile [
> > (const_int 0 [0])
> > ] VUNSPEC_BLOCKAGE) 252 {blockage}
> > (nil))
> >
> > (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> > (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> > (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> > (nil))
> >
> > is reordered into:
> >
> > (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> > (nil))
> >
> > (insn 16 14 24 (unspec_volatile [
> > (const_int 0 [0])
> > ] VUNSPEC_BLOCKAGE) 252 {blockage}
> > (nil))
> >
> > (insn 24 16 30 (set (reg/i:SI 0 r0)
> > (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> > (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> > comp-goto-2.c:26 176 {*arm_movsi_insn}
> > (nil))
> >
> > (insn 30 24 27 (set (reg/f:SI 11 fp)
> > (plus:SI (reg/f:SI 11 fp)
> > (const_int 36 [0x24]))) 4 {*arm_addsi3}
> > (nil))
> >
> > despite the blockage.
>
> Hmmm I'm not sure I see this - what's the configure and arch. specific flags
> you used just in case ?
>
Just in case - I am using -march=armv5t -marm -Os on the command line.
Ramana
>
> cheers
> Ramana
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (18 preceding siblings ...)
2011-07-18 16:36 ` ramana at gcc dot gnu.org
@ 2011-07-18 17:59 ` ebotcazou at gcc dot gnu.org
2011-09-13 8:45 ` carrot at google dot com
` (7 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-07-18 17:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #18 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-07-18 17:59:04 UTC ---
> Hmmm I'm not sure I see this - what's the configure and arch. specific flags
> you used just in case ?
Flags are just -Os.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (19 preceding siblings ...)
2011-07-18 17:59 ` ebotcazou at gcc dot gnu.org
@ 2011-09-13 8:45 ` carrot at google dot com
2011-09-14 6:27 ` carrot at google dot com
` (6 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: carrot at google dot com @ 2011-09-13 8:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
Carrot <carrot at google dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |carrot at google dot com
--- Comment #19 from Carrot <carrot at google dot com> 2011-09-13 08:37:52 UTC ---
(In reply to comment #15)
> The machine-dependent reorg pass does something unexpected:
>
> (insn 30 18 14 3 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> (insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 3 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 27 3 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -56 [0xffffffffffffffc8])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> is reordered into:
>
> (insn 14 18 16 (use (reg/f:SI 11 fp)) -1
> (nil))
>
> (insn 16 14 24 (unspec_volatile [
> (const_int 0 [0])
> ] VUNSPEC_BLOCKAGE) 252 {blockage}
> (nil))
>
> (insn 24 16 30 (set (reg/i:SI 0 r0)
> (mem/c:SI (plus:SI (reg/f:SI 11 fp)
> (const_int -20 [0xffffffffffffffec])) [6 %sfp+-20 S4 A32]))
> comp-goto-2.c:26 176 {*arm_movsi_insn}
> (nil))
>
> (insn 30 24 27 (set (reg/f:SI 11 fp)
> (plus:SI (reg/f:SI 11 fp)
> (const_int 36 [0x24]))) 4 {*arm_addsi3}
> (nil))
>
> despite the blockage.
I observed the same transformation, but in postreload pass. My command line is
"-march=armv7-a" "-mfloat-abi=soft" -Os -w
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (20 preceding siblings ...)
2011-09-13 8:45 ` carrot at google dot com
@ 2011-09-14 6:27 ` carrot at google dot com
2011-09-14 7:18 ` ebotcazou at gcc dot gnu.org
` (5 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: carrot at google dot com @ 2011-09-14 6:27 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #20 from Carrot <carrot at google dot com> 2011-09-14 03:02:03 UTC ---
> Instruction 2 and 24 refer to the same location, but have different offset
> relative to FP because the call to y changes FP. DSE doesn't (and can not, if
> it is intra-procedural) know that they both refer to the same location and
> hence thinks insn 2 is dead.
>
> It seems to me this (FP having different value after the call) can only happen
> at postreload. It seems to me that setting wild_read (not just
> non_frame_wild_read) on all calls after postreload will fix this problem.
> What's the best way to do that? Will checking for clear_alias_sets != NULL
> work?
All callee saved registers should never changed after function call. Here fp
has been changed is not because it is after a function call, it is because it
is after the target of non local goto. I'm not familiar with the implementation
of non local goto, but I guess there is some convention/protocol defines which
registers may be changed after the target of a non local goto.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (21 preceding siblings ...)
2011-09-14 6:27 ` carrot at google dot com
@ 2011-09-14 7:18 ` ebotcazou at gcc dot gnu.org
2011-09-14 20:55 ` ramana.r at gmail dot com
` (4 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-09-14 7:18 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-14 06:48:01 UTC ---
> All callee saved registers should never changed after function call. Here fp
> has been changed is not because it is after a function call, it is because it
> is after the target of non local goto. I'm not familiar with the implementation
> of non local goto, but I guess there is some convention/protocol defines which
> registers may be changed after the target of a non local goto.
That's not the problem. The problem is that the blockage isn't honored.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (22 preceding siblings ...)
2011-09-14 7:18 ` ebotcazou at gcc dot gnu.org
@ 2011-09-14 20:55 ` ramana.r at gmail dot com
2011-09-16 7:23 ` carrot at google dot com
` (3 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: ramana.r at gmail dot com @ 2011-09-14 20:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #22 from Ramana Radhakrishnan <ramana.r at gmail dot com> 2011-09-14 20:26:43 UTC ---
On 14 Sep 2011, at 07:48, "ebotcazou at gcc dot gnu.org"
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
>
> --- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-14 06:48:01 UTC ---
>> All callee saved registers should never changed after function call. Here fp
>> has been changed is not because it is after a function call, it is because it
>> is after the target of non local goto. I'm not familiar with the implementation
>> of non local goto, but I guess there is some convention/protocol defines which
>> registers may be changed after the target of a non local goto.
>
> That's not the problem. The problem is that the blockage isn't honored.
By ?
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You reported the bug.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (23 preceding siblings ...)
2011-09-14 20:55 ` ramana.r at gmail dot com
@ 2011-09-16 7:23 ` carrot at google dot com
2011-09-16 22:05 ` ebotcazou at gcc dot gnu.org
` (2 subsequent siblings)
27 siblings, 0 replies; 29+ messages in thread
From: carrot at google dot com @ 2011-09-16 7:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #23 from Carrot <carrot at google dot com> 2011-09-16 06:57:15 UTC ---
(In reply to comment #21)
> > All callee saved registers should never changed after function call. Here fp
> > has been changed is not because it is after a function call, it is because it
> > is after the target of non local goto. I'm not familiar with the implementation
> > of non local goto, but I guess there is some convention/protocol defines which
> > registers may be changed after the target of a non local goto.
>
> That's not the problem. The problem is that the blockage isn't honored.
It seems postreload.c should be changed to the following to avoid combining
--- postreload.c (revision 178904)
+++ postreload.c (working copy)
@@ -1312,7 +1312,7 @@ reload_combine (void)
is and then later disable any optimization that would cross it. */
if (LABEL_P (insn))
last_label_ruid = reload_combine_ruid;
- else if (BARRIER_P (insn))
+ else if (BARRIER_P (insn) || BLOCKAGE_P (insn))
for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
if (! fixed_regs[r])
reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;
BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any
available function/macro that implement this functionality?
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (24 preceding siblings ...)
2011-09-16 7:23 ` carrot at google dot com
@ 2011-09-16 22:05 ` ebotcazou at gcc dot gnu.org
2011-09-20 2:08 ` [Bug rtl-optimization/49452] " carrot at gcc dot gnu.org
2011-10-10 12:22 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-09-16 22:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #24 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-09-16 21:24:30 UTC ---
> It seems postreload.c should be changed to the following to avoid combining
>
> --- postreload.c (revision 178904)
> +++ postreload.c (working copy)
> @@ -1312,7 +1312,7 @@ reload_combine (void)
> is and then later disable any optimization that would cross it. */
> if (LABEL_P (insn))
> last_label_ruid = reload_combine_ruid;
> - else if (BARRIER_P (insn))
> + else if (BARRIER_P (insn) || BLOCKAGE_P (insn))
> for (r = 0; r < FIRST_PSEUDO_REGISTER; r++)
> if (! fixed_regs[r])
> reg_state[r].use_index = RELOAD_COMBINE_MAX_USES;
>
> BLOCKAGE_P (insn) is used to detect if insn is a blockage insn, is there any
> available function/macro that implement this functionality?
volatile_insn_p would seem to be appropriate.
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug rtl-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (25 preceding siblings ...)
2011-09-16 22:05 ` ebotcazou at gcc dot gnu.org
@ 2011-09-20 2:08 ` carrot at gcc dot gnu.org
2011-10-10 12:22 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: carrot at gcc dot gnu.org @ 2011-09-20 2:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #25 from carrot at gcc dot gnu.org 2011-09-20 00:57:44 UTC ---
Author: carrot
Date: Tue Sep 20 00:57:39 2011
New Revision: 178995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178995
Log:
PR rtl-optimization/49452
* postreload.c (reload_combine): Invalidate use information when across
volatile insn.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/postreload.c
^ permalink raw reply [flat|nested] 29+ messages in thread
* [Bug rtl-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
2011-06-17 11:55 [Bug tree-optimization/49452] New: New testsuite failures with arm-linux-gnueabi comp-goto failing with ramana at gcc dot gnu.org
` (26 preceding siblings ...)
2011-09-20 2:08 ` [Bug rtl-optimization/49452] " carrot at gcc dot gnu.org
@ 2011-10-10 12:22 ` rguenth at gcc dot gnu.org
27 siblings, 0 replies; 29+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-10-10 12:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
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-10-10 11:52:26 UTC ---
I supposed fixed.
^ permalink raw reply [flat|nested] 29+ messages in thread