GCC 4.6.x miscompiling arm-linux?
David Jander
david.jander at protonic.nl
Tue Sep 11 06:37:43 EDT 2012
Dear Mikael,
Thanks a lot for your help so far.
On Tue, 11 Sep 2012 11:41:08 +0200
Mikael Pettersson <mikpe at it.uu.se> wrote:
> David Jander writes:
> >
> > Dear Mikael,
> >
> > On Tue, 11 Sep 2012 10:11:02 +0200
> > Mikael Pettersson <mikpe at it.uu.se> wrote:
> >
> > > David Jander writes:
> > > >
> > > > Hi Matt,
> > > >
> > > > On Mon, 10 Sep 2012 18:11:19 +0100
> > > > Matthew Leach <matthew at mattleach.net> wrote:
> > > > > David Jander <david.jander at protonic.nl> writes:
> > > > > > ...
> > > > > > .text
> > > > > > .align 2
> > > > > > .global flexcan_chip_start
> > > > > > .type flexcan_chip_start, %function
> > > > > > flexcan_chip_start:
> > > > > > @ args = 0, pretend = 0, frame = 0
> > > > > > @ frame_needed = 0, uses_anonymous_args = 0
> > > > > > @ link register save eliminated.
> > > > > > mov r3, #0
> > > > > > cmp r0, #9
> > > > > > str r3, [r1, #0]
> > > > > > ldrle r3, [r1, #4]
> > > > > > mov r0, #0
> > > > > > str r3, [r1, #4]
> > > > > > bx lr
> > > > > > .size flexcan_chip_start, .-flexcan_chip_start
> > > > > > .ident "GCC: (OSELAS.Toolchain-2011.11.1) 4.6.2"
> > > > > > .section .note.GNU-stack,"",%progbits
> > > > > >
> > > > >
> > > > > This does indeed look wrong. I had a go at compile your code snippet the
> > > > > following assembly was produced:
> > > > >
> > > > > .text
> > > > > .align 2
> > > > > .global flexcan_chip_start
> > > > > .type flexcan_chip_start, %function
> > > > > flexcan_chip_start:
> > > > > @ Function supports interworking.
> > > > > @ args = 0, pretend = 0, frame = 0
> > > > > @ frame_needed = 0, uses_anonymous_args = 0
> > > > > @ link register save eliminated.
> > > > > cmp r0, #9
> > > > > mov r3, #0
> > > > > str r3, [r1, #0]
> > > > > mov r0, #0
> > > > > strgt r3, [r1, #4]
> > > > > bx lr
> > > > > .size flexcan_chip_start, .-flexcan_chip_start
> > > > > .ident "GCC: (GNU) 4.3.3"
> > > > > .section .note.GNU-stack,"",%progbits
> > > > >
> > > > > I think this looks correct. Perhaps you could try the angstrom arm5te
> > > > > toolchain and see if it's a toolchain issue?
> > > >
> > > > Yes, this looks a lot better, and is exactly what I get when I compile this
> > > > code with CodeSourcery GCC-4.4.1
> > > >
> > > > I have tries building gcc-4.6.3 also with OSELAS/PTXdist, and it gives the
> > > > same (wrong) result as with gcc-4.6.2
> > > >
> > > > > I think this looks correct. Perhaps you could try the angstrom arm5te
> > > > > toolchain and see if it's a toolchain issue?
> > > > >
> > > > > http://www.angstrom-distribution.org/toolchains/angstrom-2011.03-i686-linux-armv5te-linux-gnueabi-toolchain-qte-4.6.3.tar.bz2
> > > >
> > > > This toolchain is a lot older:
> > > >
> > > > $ ./usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc --version
> > > > arm-angstrom-linux-gnueabi-gcc (GCC) 4.3.3
> > > > Copyright (C) 2008 Free Software Foundation, Inc.
> > > > This is free software; see the source for copying conditions. There is NO
> > > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > > >
> > > > The tar-ball says 4.6.3, but that is probably the version number of the qte
> > > > library, not that of gcc, which is 4.3.3, It does indeed produce
> > > > the same (correct) output as in your case.
> > > >
> > > > The newest angstrom (next) toolchain has gcc version 4.5.3, and it produces
> > > > this (correct) output:
> > > >
> > > > flexcan_chip_start:
> > > > @ Function supports interworking.
> > > > @ args = 0, pretend = 0, frame = 0
> > > > @ frame_needed = 0, uses_anonymous_args = 0
> > > > @ link register save eliminated.
> > > > mov r3, #0
> > > > cmp r0, #9
> > > > str r3, [r1, #0]
> > > > mov r0, #0
> > > > strgt r3, [r1, #4]
> > > > bx lr
> > > > .size flexcan_chip_start, .-flexcan_chip_start
> > > > .ident "GCC: (GNU) 4.5.3 20110311 (prerelease)"
> > > > .section .note.GNU-stack,"",%progbits
> > > >
> > > > Anyone knows where I can download a pre-built toolchain for 32-bit linux that
> > > > is based on gcc-4.6 and/or gcc-4.7 to try out?
> > > >
> > > > I have quite a hard time believing this issue is a yet unknown bug in GCC...
> > > > I'd rather believe that I lack sufficient GCC knowledge to know how to
> > > > correctly tell the compiler that this is a memory-IO operation. Anyone knows
> > > > how to do this correctly? Or to explain why the output of gcc-4.6 looks less
> > > > optimal than the output of older versions of GCC?
> > >
> > > Well, my toolchain generates:
> > >
> > > flexcan_chip_start:
> > > @ args = 0, pretend = 0, frame = 0
> > > @ frame_needed = 0, uses_anonymous_args = 0
> > > @ link register save eliminated.
> > > mov r3, #0
> > > cmp r0, #9
> > > str r3, [r1, #0]
> > > mov r0, #0
> > > strgt r3, [r1, #4]
> > > bx lr
> > > .size flexcan_chip_start, .-flexcan_chip_start
> > > .ident "GCC: (GNU) 4.6.3 20120706 (Brewer Linux 4.6.3-3)"
> > >
> > > which looks correct.
> >
> > This is indeed strange. I have tried with unpatched gcc-4.6.3,
> > OSELAS.Toolchain gcc 4.6.2 and linaro gcc 4.6.3 (see my previous e-mail to
> > the list), and they all produce wrong results.
> > Can you tell me where I can get your toolchain (Brewer Linux)? It also looks
> > like your version is patched somehow (version number ends in -3). What patches
> > are included in this version?
>
> The toolchain isn't published anywhere, it's my private branch with lots
> of backported upstream fixes. It's not based on Linaro/Ubuntu sources.
>
> The "-3" in the version number is a package rev generated by the .src.rpm.
>
> I can make the patches available if there's confirmation that a vanilla
> upstream gcc-4.6.3 doesn't work.
I am pretty sure this is the case... do you have a patch series that you can
easily tar and mail to me? I'd like to try those patches with OSELAS, to see
if I can indeed build a gcc-4.6.3 toolchain that generates correct code.... I
already know that I can generate one that doesn't ;-)
> > > Your bug may be a consequence of using an antique gcc, how that gcc was
> > > configured, or "OSELAS/PTXdist" may have applied a broken patch to their
> > > gcc sources. When in doubt, _alway_ report suspected gcc problems to whoever
> > > supplied you with your gcc binaries.
> >
> > Yes, the guys from OSELAS/Pengutronix are in CC (at least Sascha was from the
> > beginning). OSELAS is based on PTXdist, and as such does not distribute
> > binaries, but rather as build-scripts (recipes) a la gentoo.
> >
> > > If you do decide to report this to gcc.gnu.org's bugzilla, be prepared to:
> > > 1: first reproduce the bug with a gcc built from unmodified gcc 4.6.3, 4.7.1,
> > > or 4.8 sources -- older gccs are unmaintained and unsupported by upstream,
> >
> > I think I already did. I just changed the version string in OSELAS.Toolchain
> > script from 4.6.2 to 4.6.3. AFAIK (Sascha may confirm) this should
> > automatically build an unpatched version of gcc-4.6.3, since the PTXdist patch
> > series exists only for gcc-4.6.2. It worked, and it produced wrong code.
> > Should I call the GCC police?
>
> If you're sure no add-on patches were applied, then yes please do.
Pretty sure, but not 100%, so I'd like to try your patches first if you don't
mind....
> >
> > > 2: include the output of gcc -v which tells how that gcc was configured,
> > > 3: give the exact set of gcc options used then compiling the test case.
> >
> > That should be easy.
> >
> > > In this case the test case is so small it's not a problem, but in general
> > > self-contained executable tests that generate explicit runtime errors in
> > > case they were mis-compiled are preferred over tests that require a human
> > > to analyze the generated assembly code.
> >
> > That's understandable, and probably a good explanation as of why this bug may
> > have slipped so far through in the first place: not enough people looking at
> > the assembly output generated by the compiler, and thus not noticing that it
> > produces code that is wrong but produces correct results if it can be executed
> > without bus-errors. It could get noticed in code-efficiency tests though,
> > since it is a tad less optimal than what both older and newer versions of GCC
> > produce :-)
Best regards,
--
David Jander
Protonic Holland.
More information about the linux-arm-kernel
mailing list