------- Comment #7 from uros at kss-loka dot si 2005-10-04 11:38 -------
(In reply to comment #6)
>
> 1) Is the testcase from Comment #3 really hitting the same bug? since when I
> compile my original test case with -O1 -ftree-vectorize -msse it works, but
> then again the reduction might cause the differences.
Yes, it is the same bug. You have to trick gcc into this situation, where
initialization is in different BB that consumer (from .c.36.lreg):
(insn:HI 289 288 294 15 (set (reg/v/f:SI 108 [ wrkmem ])
(plus:SI (reg/f:SI 20 frame)
(const_int -92 [0xffffffa4]))) 144 {*lea_1} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 20 frame)
(const_int -92 [0xffffffa4]))
(nil)))
And in another BB:
;; Start of basic block 24, registers live: 6 [bp] 7 [sp] 16 [argp] 20 [frame]
59 94 95 96 97 98 108
(code_label:HI 396 395 397 24 439 "" [1 uses])
(note:HI 397 396 399 24 [bb 24] NOTE_INSN_BASIC_BLOCK)
(insn:HI 399 397 401 24 (set (reg:V4SI 93 [ vect_cst_.1512 ])
(vec_duplicate:V4SI (reg/v/f:SI 108 [ wrkmem ]))) 757 {*vec_dupv4si}
(nil)
(nil))
Reg 108 is now considered global, so it isn't assigned during lreg pass.
However, reg 108 initalization is fould by greg pass (just before it breaks):
.c.37.greg:
init_insns for 108: (insn_list:REG_DEP_TRUE 289 (nil))
The combination of insn 399 and insn 289 looks suspiciously close to malformed
RTL pattern. In reload.c/reload1.c, there is plenty of code special-cased to
(frame_ptr + constant) that could produce malformed RTL that is shown in
bugreport.
As further evidence, using -fomit-frame-pointer, I was not able to produce an
ICE for any testcase in this bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24160
