[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254 --- Comment #20 from Julien Margetts --- It is the gcc_assert (REG_P (operands[0])); in arm_reload_in_hi which fires, which as far as I can see is still in trunk today. At this point rtx operands[0] looks like this: 08 2d c2 7a 53 2b 00 00 The first pass through this code (no assert) looks like this: 80 b8 c1 7a 53 2b 00 00 NOTE: This was recreated by merging both patches from trunk into otherwise unchanged 4.9.3 release sources, as I am trying to back port this fix to 4.9.3
[Bug target/62254] [4.9/5/6 Regression] gcc-4.9 ICEs on linux kernel zlib for armv3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62254
--- Comment #17 from Julien Margetts ---
The following test case still fails with the patch applied (originally bug
70362)
arm-none-eabi-gcc -march=armv3m -c -o c_compat_x_tst.o
gcc/testsuite/gcc.dg/compat/scalar-by-value-4_x.c
The assert in the added by the patch is firing:
/* The slot is out of range, or was dressed up in a SUBREG. */
base = reg_equiv_address (REGNO (ref));
+
+ /* PR 62554: If there is no equivalent memory location then just move
+the value as an SImode register move. This happens when the target
+architecure variant does not have an HImode register move. */
+ if (base == NULL)
+ {
+ gcc_assert (REG_P (operands[0])); FAIL
+ emit_insn (gen_movsi (gen_rtx_SUBREG (SImode, operands[0], 0),
+ gen_rtx_SUBREG (SImode, ref, 0)));
+ return;
+ }
}
At this point I believe operands[0] is a QImode SUBREG
[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70362 Julien Margetts changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #7 from Julien Margetts --- 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
[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70362 --- Comment #5 from Julien Margetts --- 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?
[Bug target/70362] Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70362 --- Comment #3 from Julien Margetts --- 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
[Bug target/70362] New: Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70362 Bug ID: 70362 Summary: Segmentation fault compiling scalar-by-value-4_x.c for ARM arch < 4 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jmargetts at ocz dot com Target Milestone: --- 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
[Bug tree-optimization/70335] tree-switch-conversion uses erroneous sign extension of data loaded from CSWTCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70335 Julien Margetts changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Julien Margetts --- Many apologies. This is a bug in my target simulator! I saw the initial sign extended byte load in the ASM output, and suspected this was a compiler error: cmp r0, #66 movhi r2, #18 movhi r0, #0 ldrls r3, .L5 ldrsbls r0, [r3, r0]! << HERE ldr r1, .L5+4 ldrbls r2, [r3, #68] @ zero_extendqisi2 ldr r3, .L5+8 str r0, [r1] This is resolved as invalid. Sorry for wasting your time
[Bug tree-optimization/70335] New: tree-switch-conversion uses erroneous sign extension of data loaded from CSWTCH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70335 Bug ID: 70335 Summary: tree-switch-conversion uses erroneous sign extension of data loaded from CSWTCH Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jmargetts at ocz dot com Target Milestone: --- Created attachment 38044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38044&action=edit Failing test case The attached test case fails due to sign extension of the int 128 being packed into a byte in the compiler generated CSWTCH table, and then erroneously sign extended when it is loaded at run-time. In the failing case vb == 0xFF80, where it should be 0x0080 Configuration: Target: arm-none-eabi Configured with: ../gcc-4.9.3/configure --target=arm-none-eabi --prefix=/usr/julien/toolchain_build_NO_MODS/install-4.9.3 --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 Thread model: single gcc version 4.9.3 (GCC) Invocation: arm-none-eabi-gcc -Wall -Wextra -O2 -march=armv4 -o test.elf test.c Workaround: Explicitly disabling the feature with -fno-tree-switch-conversion produces a working executable NOTE: This test case is based on pr45830.c, which also fails in this configuration
