------- Comment #1 from jakub at gcc dot gnu dot org 2006-02-15 11:25 -------
What happens is that first dom1 splits the 1 << (f4 (...) - 1) shift into
1 << (3 - 1) and 1 << (0 - 1) branches depending on if fn3 (r)->e == u or not.
The latter triggers undefined behavior, but if the 1 << (3 - 1) branch is
always taken, then it will never be triggered at runtime.
D.1642 = 1 << -1;
is then expanded into RTL (not folded, since folders refuse to fold shifts by
negative value), at life1 we still have:
(insn 69 67 70 10 (set (reg:SI 66)
(const_int 1 [0x1])) 40 {*movsi_1} (nil)
(nil))
(insn 70 69 71 10 (parallel [
(set (reg:SI 61 [ D.1642 ])
(ashift:SI (reg:SI 66)
(const_int -1 [0xffffffffffffffff])))
(clobber (reg:CC 17 flags))
]) 413 {*ashlsi3_1} (insn_list:REG_DEP_TRUE 69 (nil))
(expr_list:REG_DEAD (reg:SI 66)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))))
but then combine changes that into:
(insn 71 70 72 10 (parallel [
(set (zero_extract:DI (const_int 0 [0x0])
(const_int 1 [0x1])
(const_int -1 [0xffffffffffffffff]))
(const_int 1 [0x1]))
]) 318 {*iorsi_1} (insn_list:REG_DEP_TRUE 70 (nil))
(expr_list:REG_DEAD (reg:SI 61 [ D.1642 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil))))
which is not valid RTL (zero_extract requires first arg to be REG or MEM).
I think this is not the first time we have issues with shifts by negative
value,
perhaps tree->rtl expansion could mask the shift count or something, otherwise
we'll keep finding such bugs all the time.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26300
