------- Additional Comments From hp at gcc dot gnu dot org 2004-12-20 03:40
-------
On the assumption that the above transformation is valid [because when we see
the (subreg:DI (mem:HI ...)) we should think of it as a (reg:DI ...)], we later
get (though I have no clue why there's SImode here):
Breakpoint 8, try_combine (i3=0xf6efe398, i2=0xf6efe370, i1=0x0,
new_direct_jump_p=0xfefffa28)
at /home/hp/combined/combined/gcc/combine.c:1629
i1 = (nil)
i2 = (insn 16 15 17 0 (set (subreg:DI (reg:HI 276) 0)
(plus:DI (reg:DI 272)
(subreg:DI (mem:HI (plus:DI (reg/v/f:DI 269 [ y ])
(const_int 2 [0x2])) [3 S2 A16]) 0))) 7 {adddi3}
(insn_list:REG_DEP_TRUE 12 (nil))
(expr_list:REG_DEAD (reg:DI 272)
(expr_list:REG_DEAD (reg/v/f:DI 269 [ y ])
(nil))))
i3 = (insn 17 16 18 0 (set (reg:SI 277)
(subreg:SI (reg:HI 276) 0)) 2 {movsi} (insn_list:REG_DEP_TRUE 16 (nil))
(expr_list:REG_DEAD (reg:HI 276)
(nil)))
causing gcc to end up in combine_simplify_rtx
with x = (subreg:SI (subreg:HI (plus:DI (reg:DI 272)
(subreg:DI (mem:HI (plus:DI (reg/v/f:DI 269 [ y ])
(const_int 2 [0x2])) [3 S2 A16]) 0)) 6) 0)
and now the subreg-will-be-a-reg-not-a-mem-access-in-the-outer-mode assumption
is made false, because x is transformed into
(plus:DI (reg:DI 272)
(subreg:DI (mem:SI (plus:DI (reg/v/f:DI 269 [ y ])
(const_int 6 [0x6])) [3 S4 A16]) 0))
where the mem is now an invalid address (accessing SImode at !SImode boundary)
though as the result is not a SEGV but an unexpected result, the test-case
will abort rather than the simulator simulate a SIGSEGV (or SIGBUS).
The solution should be along the lines to avoid generating the first paradoxical
subreg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18701
