--- Comment #3 from reichelt at gcc dot gnu dot org 2006-05-05 12:39
---
*** Bug 27443 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-05-05 12:41
---
Here's a testcase that crashes on x86_64-unknown-linux-gnu with -O3
or -O2 -fsee:
unsigned char foo(unsigned char i)
{
while (1 i)
--i;
return i;
}
--- Comment #5 from hjl at lucon dot org 2006-05-05 13:01 ---
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may point to a NOTE:
(note:HI 17 14 18 2
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-05 15:04 ---
(In reply to comment #5)
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g, NEXT_INSN/PREV_INSN may
--
hjl at lucon dot org changed:
What|Removed |Added
CC||denis dot nagorny at intel
||dot
--- Comment #7 from hjl at lucon dot org 2006-05-05 15:49 ---
(In reply to comment #6)
(In reply to comment #5)
There are several problems with the current SEE implementation:
1. SEE uses NEXT_INSN/PREV_INSN to find adjacent insns to check if SEE
is safe. But with -g,
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-05 16:49 ---
(In reply to comment #7)
You are right. Using next_nonnote_insn/prev_nonnote_insn won't solve -O3
(without -g). One real problem is SEE can't determine if SEE is safe by just
looking at
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-05 21:15 ---
*** Bug 27450 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-05 22:18
---
Here is another testcase:
unsigned char clip_uint8(int a)
{
if (a(~255))
return (-a)31;
return a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27437
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-05-05 22:22
---
My last case looks like HJL's 4 case. I wish x86 was not like this instead did
something different bug oh well
(insn:HI 6 8 7 2 (set (reg/v:SI 60 [ a ])
(mem/c/i:SI (reg/f:SI 16 argp) [2 a+0 S4 A32])) 34
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-04 19:21 ---
One reduced testcase while bootstrapping:
int partition_new (int *e1, int *e2)
{
if (e1 e2)
return -1;
else if (e1 e2)
return 1;
return 0;
}
--
pinskia at gcc dot gnu dot org changed:
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-04 23:01 ---
(In reply to comment #1)
One reduced testcase while bootstrapping:
In that testcase, we produce a subreg of mode QI and also a zero entend of SI.
Both of those look wrong in general, maybe that is just
12 matches
Mail list logo
