--- Comment #18 from steven at gcc dot gnu dot org 2005-10-31 17:14 ---
See comment #16 for a patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-31 17:16
---
(In reply to comment #18)
See comment #16 for a patch.
More than that, it has been posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01792.html
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #20 from hubicka at gcc dot gnu dot org 2005-10-31 18:45
---
Patch comitted. For some reason don't seem to appear in logs?
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from hubicka at gcc dot gnu dot org 2005-10-30 18:00
---
testing fix that should make legitimize_pic_address correctly decompose the
address. Similar to Steven's but I think it actually works ;)
Index: config/i386/i386.c
--- Comment #17 from mmitchel at gcc dot gnu dot org 2005-10-31 03:06
---
This prevents compiling a reasonably popular program; it's a showstopper.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from pluto at agmk dot net 2005-10-19 13:50 ---
(In reply to comment #13)
The testcase in comment #8 still triggers an ICE if run with -O -mtune=k8
-fPIC.
it works with my patched gcc41:
(...)
.section.data.rel.ro,aw,@progbits
.align 8
.LC1:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |critical
GCC build triplet|x86_64-linux-gnu|
GCC
--- Comment #13 from kazu at gcc dot gnu dot org 2005-10-10 03:20 ---
The testcase in comment #8 still triggers an ICE if run with -O -mtune=k8
-fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--
What|Removed |Added
Target Milestone|4.0.2 |4.0.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-07-06
17:03 ---
Postponed until 4.0.2.
--
What|Removed |Added
Target Milestone|4.0.1
--- Additional Comments From rth at gcc dot gnu dot org 2005-06-08 00:08
---
This patch trivially fixes the problem because the argument to
legitimate_pic_address_disp_p is incorrect, and it will always
return false.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-21 07:00
---
Steven, any update on this one? Would you like to get it assigned to?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--
What|Removed |Added
Target Milestone|4.0.0 |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
16:03 ---
Needs -O -mtune=k8 -fPIC of course. -fPIC seems to cause the problem.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
16:08 ---
Double *sigh*.
The old loop optimizer introduces the offending insn. From the .loop dump:
Insn 26: regno 70 (life 1), move-insn forces 25 savings 1 moved to 56
Hoisted regno 74 r/o from (mem/u/c:DI
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:24 ---
After CSE1 (t.c.04.cse) we have:
(insn 20 18 22 1 (set (reg:DI 66)
(mem/u/c:DI (const:DI (unspec:DI [
(symbol_ref:DI (bar) [flags 0x40] var_decl
0x2a95a2f000 bar)
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:39 ---
The offending insn is created by emit_move_insn in loop.c, here:
2354start_sequence ();
2355emit_move_insn (m-insert_temp ? newreg : m-set_dest,
2356
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
17:52 ---
My RTL-fu is way below par, so perhaps this doesn't make sense at all, but...
It seems that emit_move_insn must always produce valid move insns. So it
should check that an immediate is a valid PIC
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
19:03 ---
FWIW, smallest test case I could find:
extern struct bar_t bar;
void
foo (void)
{
void **p;
do {
*p++ = ((unsigned char *) bar + ((unsigned long int) 1L 31));
} while (p);
}
--
--- Additional Comments From steven at gcc dot gnu dot org 2005-04-10
21:05 ---
Alexandre Oliva pointed out to me that it was probably the expander who
should produce a proper legitimate insn. I looked at this some more and
found that in legitimize_pic_address we do not check if a
20 matches
Mail list logo
