Created attachment 29609 [details]
(originally posted on http://gcc.gnu.org/ml/gcc/2013-03/msg00051.html)
At Mozilla, we've encountered a GCC 4.6 miscompilation in the ARMv6
build of Firefox for Android. We'd like to evaluate whether this bug is
hitting us in more places than the one we spotted. To that end, we'd
need to know what particular bug in GCC leads to this miscompilation.
The attached file is the preprocessed source, slightly simplified, and with enough additions to allow it to be self-contained and with a main() that is able to act on the miscompilation being there or not.
I was able to reproduce the miscompilation with both the GCC 4.6 from the
Android NDK r8d and 4.6.3 from Debian unstable. It apparently happens
for any -march, with -marm, but not -mthumb. It happens at -Os but not
The problematic assembly looks like the following. It corresponds to
the C code after the second call to DER_SetUInteger in sftk_mkPrivKey::
mov r3, #0
cmp sl, r3
movne r0, #2
moveq r0, r3
sl/r10 is never set anywhere in the function, so we're getting random
This doesn't happen with GCC 4.7, which suggests it may be a known bug.
(On an ARM host:)
$ gcc -o pkcs11 pkcs11.i -marm -Os -fno-inline
$ gcc -o pkcs11 pkcs11.i -marm -O2 -fno-inline
I can reproduce the runtime failure on armv5tel-linux-gnueabi with vanilla gcc-4.6.3. Trunk works, as does my heavily patched 4.6-based system compiler.
I'll investigate some more later today.
The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 fix.
The arm-eabi target is also affected by this bug.
(In reply to comment #2)
> The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 fix.
Is there a back port available as a patch? A simple "git cherry-pick eed2904aa7a3ce889e8a0dd8e7ec59f9190ce5fe" in the 4.6 branch does not work due to undefined references to "alloc_insn_link".
Created attachment 29613 [details]
backport of r183512/PR48308 to 4.6 branch
This is the backport I've been using since early June 2012. The original patch required adjustments related to how LOG_LINKS are stored. Tested extensively on x86_64, sparc64, powerpc64, armv5te, and m68k.
Thanks for tracking it down.
*** This bug has been marked as a duplicate of bug 48308 ***