Bug 56561 - Miscompilation with -Os -arm
Summary: Miscompilation with -Os -arm
Status: RESOLVED DUPLICATE of bug 48308
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.6.3
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-07 12:46 UTC by Mike Hommey
Modified: 2013-03-10 09:20 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Testcase (42.33 KB, application/octet-stream)
2013-03-07 12:46 UTC, Mike Hommey
Details
backport of r183512/PR48308 to 4.6 branch (823 bytes, patch)
2013-03-08 08:23 UTC, Mikael Pettersson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Hommey 2013-03-07 12:46:35 UTC
Created attachment 29609 [details]
Testcase

(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
-O2.

The problematic assembly looks like the following. It corresponds to
the C code after the second call to DER_SetUInteger in sftk_mkPrivKey::

  bl      DER_SetUInteger(PLT)
  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
behaviour.

This doesn't happen with GCC 4.7, which suggests it may be a known bug.
Any ideas?

(On an ARM host:)
$ gcc -o pkcs11 pkcs11.i -marm -Os -fno-inline
./pkcs11
$ ./pkcs11
FAIL
$ gcc -o pkcs11 pkcs11.i -marm -O2 -fno-inline
./pkcs11
$ ./pkcs11
PASS
Comment 1 Mikael Pettersson 2013-03-07 13:37:51 UTC
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.
Comment 2 Mikael Pettersson 2013-03-07 18:14:17 UTC
The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 fix.
Comment 3 Sebastian Huber 2013-03-08 07:59:54 UTC
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".
Comment 4 Mikael Pettersson 2013-03-08 08:23:31 UTC
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.
Comment 5 Mike Hommey 2013-03-10 09:20:05 UTC
Thanks for tracking it down.

*** This bug has been marked as a duplicate of bug 48308 ***