This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tracking the source of an ARM miscompilation with gcc 4.6
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Mike Hommey <mh-gcc at glandium dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 7 Mar 2013 00:28:22 -0800
- Subject: Re: Tracking the source of an ARM miscompilation with gcc 4.6
- References: <20130307082424.GA26191@glandium.org>
On Thu, Mar 7, 2013 at 12:24 AM, Mike Hommey <mh-gcc@glandium.org> wrote:
> Hi,
>
> 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. 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.
No attached file. Also does -fno-strict-aliasing fix it?
Thanks,
Andrew
>
> 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?
>
> Cheers,
>
> Mike