Internal compiler error in push_reload during bootstrap stage 2

[Matthew Gretton-Dann]

Backport fix for upstream issue which is latent in GCC Linaro 4.7:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184

Indeed, the included test.ii does not make GCC Linaro 4.7 crash, but since we backported the patch which exposed the bug on trunk, we have to backport the fix too.

[Matthew Gretton-Dann (matthew-gretton-dann)]

Created attachment 29337
Reduced test case

When bootstrapping on an ARM target I get the following error:

/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/./prev-gcc/xg++ -B/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/./prev-gcc/ -B/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/install/arm-linux-gnueabi/bin/ -nostdinc++ -B/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/src/.libs -B/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/include/arm-linux-gnueabi -I/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/include -I/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/gcc-4.8~svn195568/libstdc++-v3/libsupc++ -L/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/src/.libs -L/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/build/prev-arm-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../gcc-4.8~svn195568/gcc -I../../../gcc-4.8~svn195568/gcc/. -I../../../gcc-4.8~svn195568/gcc/../include -I../../../gcc-4.8~svn195568/gcc/../libcpp/include -I../../../gcc-4.8~svn195568/gcc/../libdecnumber -I../../../gcc-4.8~svn195568/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../gcc-4.8~svn195568/gcc/../libbacktrace ../../../gcc-4.8~svn195568/gcc/lto-streamer-out.c -o lto-streamer-out.o
../../../gcc-4.8~svn195568/gcc/lto-streamer-in.c: In function 'void lto_input_function_body(lto_file_decl_data*, tree, const char*)':
../../../gcc-4.8~svn195568/gcc/lto-streamer-in.c:1003:1: internal compiler error: in push_reload, at reload.c:1014
 }
 ^
0x6d1a41 push_reload(rtx_def*, rtx_def*, rtx_def**, rtx_def**, reg_class, machine_mode, machine_mode, int, int, int, reload_type)
 ../../../gcc-4.8~svn195568/gcc/reload.c:1012
0x6daa8d find_reloads(rtx_def*, int, int, int, short*)
 ../../../gcc-4.8~svn195568/gcc/reload.c:4099
0x6e6d8b calculate_needs_all_insns
 ../../../gcc-4.8~svn195568/gcc/reload1.c:1520
0x6e560b reload(rtx_def*, int)
 ../../../gcc-4.8~svn195568/gcc/reload1.c:941
0x5f1843 do_reload
 ../../../gcc-4.8~svn195568/gcc/ira.c:4635
0x5f1a33 rest_of_handle_reload
 ../../../gcc-4.8~svn195568/gcc/ira.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[7]: *** [lto-streamer-in.o] Error 1

GCC has been configured as follows:

--prefix=/cbuild/slaves/tcpandas/gcc-4.8~svn195568/gcc/default/install --enable-languages=c,c++,objc,obj-c++,fortran,lto --enable-linker-build-id --with-mode=thumb --with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=neon --with-float=softfp --build=arm-linux-gnueabi

Attached test case is a redu...

[Matthew Gretton-Dann (matthew-gretton-dann)]

I can reproduce this is in a compiler targeted for arm-none-eabi (and without needing libraries built) as follows:

Compiler configured with: /work/sources/gcc-fsf/master/configure --target=arm-none-eabi --prefix=/work/builds/gcc-fsf-master/tools --without-headers --with-newlib --disable-shared --disable-threads --disable-libssp --disable-libgomp --disable-libmudflap --disable-libatomic --without-libquadmath --disable-libquadmath --enable-languages=c,c++

./cc1plus -fpreprocessed test.ii -mthumb -march=armv7-a -mfpu=neon -mfloat-abi=softfp -mtune=cortex-a9 -O2 -o /tmp/tmp.s

RTL dumps of 208r.ira and 208r.reload are attached from running the above command.

The assert producing the ICE is:

      int regno = REGNO (out);
      gcc_assert (regno < FIRST_PSEUDO_REGISTER
    || reg_renumber[regno] >= 0
    || reg_equiv_constant (regno) == NULL_RTX);

out: (reg:DI 358 [315])
regno: 358
reg_renumber[regno] = -1
reg_equiv_constant (regno) = ? (Can't get GDB to print the value)

[Matthew Gretton-Dann (matthew-gretton-dann)]

Created attachment 29357
RTL dump from IRA phase

[Matthew Gretton-Dann (matthew-gretton-dann)]

Created attachment 29358
RTL dump from reload phase

[Uweigand-gcc (uweigand-gcc)]

This is weird; I cannot reproduce the behaviour even with the exact configure and command lines you specify. I've been using SVN rev. 195717; which revision do you see the problem with?

In the generated test.ii.208r.ira file I get, I see different register uses even before IRA, compared to your version.

Would you mind sending me (offline) a full set of the dump files so I can see where my compile run starts to diverge from yours?

[Uweigand-gcc (uweigand-gcc)]

Depending on configure tests of the installed (cross-)assembler, the ICE may not occur. In those cases, I'm now able to reliably reproduce the ICE by using -fno-section-anchors (in addition to the flags given above).

[Uweigand-gcc (uweigand-gcc)]

The problem occurs with the following insn:

(insn 539 383 384 46
 (set (reg:DI 355 [313]) (const_int 256 [0x100]))
 test.ii:128 643 {*movdi_vfp}
 (expr_list:REG_EQUIV (const_int 256 [0x100])
 (nil)))

Register 355 is recognized as always-equal to the constant 256, and insn 539 is the insn that originally sets up the equivalence. If the register doesn't get a hard reg, what ought to happen is that users of reg 355 get replaced by the constant, and the insn setting the equivalence ought to be deleted. Because the insn will get deleted anyway, it also ought to be skipped for find_reloads.

To achieve that, reg_equiv_constant(355) should hold the constant, and reg_equiv_init(355) should point to the above insn. However, what actually happens in this test case is that reg_equiv_init(355) is NULL. Therefore, the insn is *not* skipped for find_reloads, which then aborts since it tries to push an output reload for an always-constant register, which is not supposed to happen.

Now the register is somewhat special in that it was created by IRA via live range splitting. The original register was reg 313; and this still has reg_equiv_init(313) pointing to the above insn. However, reg_equiv_init(355) is NULL. There is a routine fix_reg_equiv_init in ira.c which appears to be intended to fix the reg_equiv_init settings of new registers created by live range splitting. However, this doesn't seem to have worked in this case ...

Unfortunately I'm not really familiar with the live range splitting code; maybe Vladimir can help with this?

[Vmakarov-4 (vmakarov-4)]

(In reply to comment #6)
>
> Unfortunately I'm not really familiar with the live range splitting code; maybe
> Vladimir can help with this?

Yes, Ulrich. I've started to work on this.

[Vmakarov-4 (vmakarov-4)]

Author: vmakarov
Date: Wed Feb 13 17:40:22 2013
New Revision: 196019

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=196019
Log:
2013-02-13 Vladimir Makarov <email address hidden>

 PR target/56184
 * ira.c (max_regno_before_ira): Move from ...
 (ira): ... here.
 (fix_reg_equiv_init): Use max_regno_before_ira instead of
 vec_safe_length.

2013-02-13 Vladimir Makarov <email address hidden>

 PR target/56184
 * gcc.target/arm/pr56184.C: New test.

Added:
    trunk/gcc/testsuite/gcc.target/arm/pr56184.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira.c
    trunk/gcc/testsuite/ChangeLog

[Jakub-gcc (jakub-gcc)]

Fixed.

[Ryan S. Arnold (ryan-arnold)]

Yvan will backport this into Linaro GCC 4.7 for the 2014.04 GCC package release.