[Retrying in plain text] Hi
Background info: This question is prompted from debugging a segfault reported at https://bugs.launchpad.net/gcc-linaro/+bug/1215925?comments=all. The segfault only occurs on gcc linaro-4.7 on an arm target[1]. However, similar RTL appears in fsf 4.7, so it's not a Linaro-specific problem. The test case is compiled with: $ gcc -c upsampling_neon.c -march=armv7-a -mfloat-abi=softfp -mfpu=neon -O3 -frename-registers -mtune=cortex-a9 -marm -g The question: The insn which causes the segfault is: (debug_insn 1548 1547 1886 11 (var_location:V4HI __b (subreg:V4HI (reg:V8HI 125 d31 [orig:657 vr ] [657]) 0)) upsampling_neon.c:850 -1 (nil)) The variable vr is declared as a NEON vector of 8 16bit integers, and -frename-registers has caused it to be separated into 2 64bit parts. So the register allocation is ok, but if considered in isolation the part which reads (reg:V8HI 125 d31 [orig:657 vr ] [657]) represents a non-existent register, as the last physical register is d31 (regnos 125,126). When this is processed by sched_analyze_2 in sched-deps.c, the subreg is handled by treating it as the included (reg), and it therefore adds dependencies on invalid physical registers, which leads to a segfault. If the variable was not assigned to d31 (as in fsf 4.7), then it would not crash, but would add false dependencies. So, my question is: Is the above RTL valid? In other words, should sched-deps.c handle this, or should all reg RTL expressions represent fully valid registers? Thanks for any insight, Charles [1] gcc -v reports: Configured with: /home/cbaylis/srcarea/gcc/gcc-linaro-4.7/configure --prefix=/home/cbaylis/tools//tools-arm-unknown-linux-gnueabihf-linaro-4.7 --target=arm-unknown-linux-gnueabihf --enable-languages=c,c++ --with-sysroot=/home/cbaylis/tools//sysroot-arm-unknown-linux-gnueabihf-linaro-4.7 --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=softfp --with-thumb
