GCC 4.6.x miscompiling arm-linux?

[david.jander@protonic.nl (David Jander)]

Dear Mikael,

Thanks a lot for your help so far.

On Tue, 11 Sep 2012 11:41:08 +0200
Mikael Pettersson <mikpe@it.uu.se> wrote:

> David Jander writes:
>  > 
>  > Dear Mikael,
>  > 
>  > On Tue, 11 Sep 2012 10:11:02 +0200
>  > Mikael Pettersson <mikpe@it.uu.se> wrote:
>  > 
>  > > David Jander writes:
>  > >  > 
>  > >  > Hi Matt,
>  > >  > 
>  > >  > On Mon, 10 Sep 2012 18:11:19 +0100
>  > >  > Matthew Leach <matthew@mattleach.net> wrote:
>  > >  > > David Jander <david.jander@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.