This testcase fails with a segmentation fault on ARM architectures less then v4 (I.e. where halfword load/store are synthesised from byte accesses) /usr/julien/toolchain_build_rel/gcc-4.9.3/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c:74:1: internal compiler error: Segmentation fault T(cs, _Complex short, CINT (1, 2)) ^ 0x83650f crash_signal ../../gcc-4.9.0/gcc/toplev.c:337 0xa4bf2c arm_reload_out_hi(rtx_def**) ../../gcc-4.9.0/gcc/config/arm/arm.c:15063 0xa8475f gen_reload_outhi(rtx_def*, rtx_def*, rtx_def*) ../../gcc-4.9.0/gcc/config/arm/arm.md:7035 0x751f5d check_and_process_move ../../gcc-4.9.0/gcc/recog.h:285 0x751f5d curr_insn_transform ../../gcc-4.9.0/gcc/lra-constraints.c:3282 0x752c68 lra_constraints(bool) ../../gcc-4.9.0/gcc/lra-constraints.c:4216 0x744566 lra(_IO_FILE*) ../../gcc-4.9.0/gcc/lra.c:2353 0x70e435 do_reload ../../gcc-4.9.0/gcc/ira.c:5457 0x70e435 rest_of_handle_reload ../../gcc-4.9.0/gcc/ira.c:5598 0x70e435 execute ../../gcc-4.9.0/gcc/ira.c:5627 Please submit a full bug report, with preprocessed source if appropriate. Configured with: ../gcc-4.9.0/configure --target=arm-none-eabi --enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-multilib --disable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-libunwind --with-system-zlib --disable-newlib-supplied-syscalls arm-none-eabi-gcc -c -o c_compat_x_tst.o gcc-4.9.3/gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c -march=armv3m This problem does not exist in 4.8.5, but does in 4.9.0
Looks like a dup of PR62254 ?
dup confirmed. *** This bug has been marked as a duplicate of bug 62254 ***
Are you suggesting you confirmed the patch associated with bug 62254 fixes this issue? As far as I can tell, in isolation at least, it does not
(In reply to Julien Margetts from comment #3) > Are you suggesting you confirmed the patch associated with bug 62254 fixes > this issue? > > As far as I can tell, in isolation at least, it does not > Are you suggesting you confirmed the patch associated with bug 62254 fixes > this issue? > > As far as I can tell, in isolation at least, it does not There are 2 patches associated with PR62254 - from my experiments the failure went away with a tree that had both patches applied, could you check ?
Yes, I applied both patches, and the test failure is still present, but on closer inspection, it is no longer a segfault, but an internal compiler error: The new assertion in the patch is firing: gcc_assert (REG_P (operands[0])); The discussion in PR62254 suggests not all cases are covered (hence the new asserts I guess) so I think this is just another as yet unreached corner case I guess either this bug, or 62254 should be re-opened?
Fails at O0 in this case, I cannot type. I still think this is a tail from PR62254 and that should just be reopened.
I agree, adding Nick Clifton on CC as the originator of the PR62254 patch FWIW: It turns out when the assert fires: GET_MODE(SUBREG_REG(operands[0])) == QImode I will re-open PR62254
(In reply to Ramana Radhakrishnan from comment #6) > Fails at O0 in this case, I cannot type. I still think this is a tail from > PR62254 and that should just be reopened. I cannot reproduce this failure. Ie when I compile this test case everything works, at -O0 all the way up to -O3. This is with today's mainline sources, which has *both* of the patches from PR 62254 applied. These sources no longer contain this assertion: gcc_assert (REG_P (operands[0])); although they do contain: gcc_assert (REG_P (outval) || SUBREG_P (outval)); If the problem really does exist, could someone tell me what outval looks like when the assertion is triggered ? Cheers Nick