This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c
- From: "hp at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 20 Dec 2004 03:40:50 -0000
- Subject: [Bug target/18701] [4.0 regression] mmix-knuth-mmixware gcc.c-torture/execute failures: 20010224-1.c, 20020216-1.c, 20040218-1.c, 20040709-2.c
- References: <20041128144007.18701.hp@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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