[Bug target/54699] [4.8 Regression] [SH] gfortran.dg/class_array_9.f03 ICEs

["kkojima at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.