@@ -1,3 +1,10 @@
+2014-01-27 Jakub Jelinek <jakub@redhat.com>
+
+ PR bootstrap/59934
+ * expmed.h (expmed_mode_index): Rework so that analysis and optimziers
+ know when the MODE_PARTIAL_INT and MODE_VECTOR_INT cases can never be
+ reached.
+
2014-01-27 James Greenhalgh <james.greenhalgh@arm.com>
* common/config/arm/arm-common.c
@@ -221,12 +221,21 @@ expmed_mode_index (enum machine_mode mode)
case MODE_INT:
return mode - MIN_MODE_INT;
case MODE_PARTIAL_INT:
- return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT;
+ /* If there are no partial integer modes, help the compiler
+ to figure out this will never happen. See PR59934. */
+ if (MIN_MODE_PARTIAL_INT != VOIDmode)
+ return mode - MIN_MODE_PARTIAL_INT + NUM_MODE_INT;
+ break;
case MODE_VECTOR_INT:
- return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT;
+ /* If there are no vector integer modes, help the compiler
+ to figure out this will never happen. See PR59934. */
+ if (MIN_MODE_VECTOR_INT != VOIDmode)
+ return mode - MIN_MODE_VECTOR_INT + NUM_MODE_IP_INT;
+ break;
default:
- gcc_unreachable ();
+ break;
}
+ gcc_unreachable ();
}
/* Return a pointer to a boolean contained in EOC indicating whether
As discussed in the PR, when a port does not have partial integer or vector integer modes, expmed_mode_index will not be called with those modes. However, our VRP analysis isn't aware of those constraints and has to assume the MODE_PARTIAL_INT and MODE_VECTOR_INT cases could be used. That in turn can cause a false positive array index out of range warning, which is causing the s390 and PA ports to fail to bootstrap. This patch almost restores the s390x bootstrap -- it's currently failing building libjava in stage3. [ ... ] from ../../../../../../gcc/libjava/classpath/tools/sun/rmi/rmic/Main.java:58, from <built-in>:3: ../../../../../../gcc/libjava/classpath/tools/external/asm/org/objectweb/asm/util/TraceMethodVisitor.java:286:0: note: non-delegitimized UNSPEC UNSPEC_PLTOFF (12) found in variable location gcj: internal compiler error: Segmentation fault (program jc1) 0x80010353 execute ../../gcc/gcc/gcc.c:2841 0x8001060d do_spec_1 ../../gcc/gcc/gcc.c:4641 0x8001394d process_brace_body ../../gcc/gcc/gcc.c:5924 0x8001394d handle_braces ../../gcc/gcc/gcc.c:5838 [ ... ] Regardless, this patch from Jakub is clearly a step forward and I believe it's highly unlikely to be the root cause of this stage3 error. I also bootstrapped and regression tested the patch on x86-64-unknown-linux-gnu. Installed on the trunk. Andreas -- if you could help with debugging the stage3 libjava compilation failure, it'd be greatly appreciated. Thanks, Jeff