http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54699
--- Comment #5 from Kazumoto Kojima <kkojima at gcc dot gnu.org> 2012-10-10
00:03:54 UTC ---
(In reply to comment #4)
> I'm wondering whether there is anything after reload that actually needs
> address validation. I guess that after the reload pass pretty much everything
> should have been fixed up which could generate invalid addresses that need to
> be transformed. Of course, in one of the split passes after reload or the
> peephole2 pass somebody could write a pattern that would result in an invalid
> address. But even now with the address checking after reload, if there is an
> invalid address left after reload, which pass would legitimize it?
*legitimate_address_p is a query function and possibly used to
verify some transformation of addressing. It seems to me that
> sh_legitimate_address_p (enum machine_mode mode, rtx x, bool strict)
> {
> + if (reload_completed)
> + return true;
will open a can of worms. With this change, I've got
../../../LOCAL/trunk/libgcc/libgcc2.c: In function '__muldc3':
../../../LOCAL/trunk/libgcc/libgcc2.c:1929:1: internal compiler error:
Segmentation fault
}
^
0x852c3a0 crash_signal
../../LOCAL/trunk/gcc/toplev.c:335
0x8772b21 sh_print_operand_address
../../LOCAL/trunk/gcc/config/sh/sh.c:1050
0x8308eba output_address(rtx_def*)
../../LOCAL/trunk/gcc/final.c:3680
during building libgcc on sh4-unknown-linux-gnu. gdb backtrace says
(gdb) fr 5
#5 0x083093a5 in output_asm_insn (templ=0x8a2621c "fmov.s\t%1,%0",
operands=0x8bc10c0) at ../../LOCAL/trunk/gcc/final.c:3562
3562 output_operand (operands[opnum], 0);
(gdb) call debug_rtx(operands[0])
(mem/c:SF (plus:SI (plus:SI (reg:SI 0 r0)
(reg/f:SI 15 r15))
(const_int 4 [0x4])) [2 %sfp+-24 S8 A32])
(gdb) call debug_rtx(operands[1])
It looks we've got reg+reg+const addressing. It seems that
reload_completed simply means that hard register are allocated
already but doesn't mean transformations of addressing are done.
Splitting movsf_ie would be the way to go, I guess.
