GCC 4.6.x miscompiling arm-linux?

GCC 4.6.x miscompiling arm-linux?

[David Jander]

Hi all,

This probably is a GCC problem, but I am not entirely sure, and since I
stumbled upon this issue while debugging a kernel driver, it may have
something to do with how linux handles io-memory.
The symptoms became apparent when compiling latest mainline linux kernel for
the Freescale i.MX28 SoC, building the flexcan driver
(drivers/net/can/flexcan.c), using OSELAS.Toolchain GCC-4.6.2 for arm5te.

In the function flexcan_chip_start(), at line 775:

...
	if (priv->devtype_data->hw_ver >= 10)
		flexcan_write(0x0, &regs->rxfgmask);
...

The if() argument is false, but the CPU nevertheless crashes on a bus-error
writing to register &regs->rxfgmask!! The catch is, that in assembly, this
register is being _read_ conditionally, and then written _always_. Since this
register does not exist on the i.MX28 (hw_ver == 3), the CPU crashes.

I have no idea why GCC thinks it can do such a thing to a volatile memory
address. I have been able to reduce the code to just this bit:

/* Structure of the hardware registers */
struct flexcan_regs {
	unsigned int mcr;
	unsigned int rxfgmask;
};

#define flexcan_read(a)	(*(volatile unsigned int *)(a))
#define flexcan_write(v,a)	(*(volatile unsigned int *)(a) = (v))

int flexcan_chip_start(int ver, struct flexcan_regs *regs)
{
	flexcan_write(0, &regs->mcr);

	if (ver >= 10)
		flexcan_write(0, &regs->rxfgmask);

	return 0;
}

With GCC 4.6.x, using just "-Os", this compiles to:

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

Notice the ldrle instruction followed by str. The "str r3, [r1, #4]" is always
executed, which would do no harm if it was a regular piece of RAM, but in this
case it is a non-existent peripheral register!
Is there a new way to tell this to the compiler? Am I missing something? Or it
this a GCC bug, and should I spam their respective mailing lists with this?

Any hint appreciated.

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Matthew Leach]

Hi David,

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?

http://www.angstrom-distribution.org/toolchains/angstrom-2011.03-i686-linux-armv5te-linux-gnueabi-toolchain-qte-4.6.3.tar.bz2

Thanks,
Matt

GCC 4.6.x miscompiling arm-linux?

[David Jander]

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?

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[David Jander]

Hi all,

On Tue, 11 Sep 2012 09:27:53 +0200
David Jander <david.jander@protonic.nl> wrote:
> 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?

I finally found two linaro toolchains that I could download and try. The
results are rather interesting though:

1.- Ubuntu package gcc-4.6-arm-linux-gnueabi 4.6.3-1ubuntu5cross1.62:

flexcan_chip_start:
        .fnstart
        @ 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
        .fnend
        .size   flexcan_chip_start, .-flexcan_chip_start
        .ident  "GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3"
        .section        .note.GNU-stack,"",%progbits

Wrong code.

2. Linaro gcc-linaro-arm-linux-gnueabihf-2012.08-20120827_linux gcc 4.7.2:

flexcan_chip_start:
        .fnstart
        @ 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
        .fnend
        .size   flexcan_chip_start, .-flexcan_chip_start
        .ident  "GCC: (crosstool-NG linaro-1.13.1-2012.08-20120827 - Linaro GCC 2012.08) 4.7.2 20120731 (prerelease)"
        .section        .note.GNU-stack,"",%progbits

This looks correct again! Could it be that all versions 4.6.x of gcc are
broken for ARM??

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Mikael Pettersson]

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.

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.

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,
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.

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.

GCC 4.6.x miscompiling arm-linux?

[David Jander]

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?

> 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?

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

GCC 4.6.x miscompiling arm-linux?

[Mikael Pettersson]

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.

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

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

GCC 4.6.x miscompiling arm-linux?

[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.

GCC 4.6.x miscompiling arm-linux?

[Mikael Pettersson]

David Jander writes:
 > > 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 ;-)
 > 
...
 > > 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....

And I'd like to confirm first. Please tell us the following:

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

and I'll check if vanilla upstream gcc is broken or not.

GCC 4.6.x miscompiling arm-linux?

[David Jander]

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

> David Jander writes:
>  > > 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 ;-)
>  > 
> ...
>  > > 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....
> 
> And I'd like to confirm first. Please tell us the following:
> 
>  > >  > > 2: include the output of gcc -v which tells how that gcc was configured,

Using built-in specs.
COLLECT_GCC=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3
COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/libexec/gcc/arm-v5te-linux-gnueabi/4.6.3/lto-wrapper
Target: arm-v5te-linux-gnueabi
Configured with: /home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/build-cross/gcc-4.6.3/configure --target=arm-v5te-linux-gnueabi --with-sysroot=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3
-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-v5te-linux-gnueabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.1 --with-system-zlib --with-gmp=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te
-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --with-mpfr=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --prefix=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-shared --disable-libssp --enable-checking=release
Thread model: posix
gcc version 4.6.3 (OSELAS.Toolchain-2011.11.1)

>  > >  > > 3: give the exact set of gcc options used then compiling the test case.

If I type this in a terminal:


$ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -

struct flexcan_regs {
        unsigned int mcr;
        unsigned int rxfgmask;
};

#define flexcan_read(a) (*(volatile unsigned int *)(a))
#define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))

int flexcan_chip_start(int ver, struct flexcan_regs *regs)
{
        flexcan_write(0, &regs->mcr);

        if (ver >= 10)
                flexcan_write(0, &regs->rxfgmask);

        return 0;
}


I get this output after hitting <CTRL-D>:

        .cpu arm926ej-s
        .fpu softvfp
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 4
        .eabi_attribute 18, 4
        .file   ""
        .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.3"
        .section        .note.GNU-stack,"",%progbits


Do you need more information?

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Mikael Pettersson]

David Jander writes:
 > On Tue, 11 Sep 2012 13:35:40 +0200
 > Mikael Pettersson <mikpe@it.uu.se> wrote:
 > 
 > > David Jander writes:
 > >  > > 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 ;-)
 > >  > 
 > > ...
 > >  > > 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....
 > > 
 > > And I'd like to confirm first. Please tell us the following:
 > > 
 > >  > >  > > 2: include the output of gcc -v which tells how that gcc was configured,
 > 
 > Using built-in specs.
 > COLLECT_GCC=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3
 > COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/libexec/gcc/arm-v5te-linux-gnueabi/4.6.3/lto-wrapper
 > Target: arm-v5te-linux-gnueabi
 > Configured with: /home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/build-cross/gcc-4.6.3/configure --target=arm-v5te-linux-gnueabi --with-sysroot=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3
 > -glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-v5te-linux-gnueabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.1 --with-system-zlib --with-gmp=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te
 > -linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --with-mpfr=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --prefix=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-shared --disable-libssp --enable-checking=release
 > Thread model: posix
 > gcc version 4.6.3 (OSELAS.Toolchain-2011.11.1)
 > 
 > >  > >  > > 3: give the exact set of gcc options used then compiling the test case.
 > 
 > If I type this in a terminal:
 > 
 > 
 > $ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -
 > 
 > struct flexcan_regs {
 >         unsigned int mcr;
 >         unsigned int rxfgmask;
 > };
 > 
 > #define flexcan_read(a) (*(volatile unsigned int *)(a))
 > #define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))
 > 
 > int flexcan_chip_start(int ver, struct flexcan_regs *regs)
 > {
 >         flexcan_write(0, &regs->mcr);
 > 
 >         if (ver >= 10)
 >                 flexcan_write(0, &regs->rxfgmask);
 > 
 >         return 0;
 > }
 > 
 > 
 > I get this output after hitting <CTRL-D>:
 > 
 >         .cpu arm926ej-s
 >         .fpu softvfp
 >         .eabi_attribute 20, 1
 >         .eabi_attribute 21, 1
 >         .eabi_attribute 23, 3
 >         .eabi_attribute 24, 1
 >         .eabi_attribute 25, 1
 >         .eabi_attribute 26, 2
 >         .eabi_attribute 30, 4
 >         .eabi_attribute 18, 4
 >         .file   ""
 >         .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.3"
 >         .section        .note.GNU-stack,"",%progbits
 > 
 > 
 > Do you need more information?

No, I can reproduce the bug with vanilla gcc-4.6.3; vanilla 4.7.1 and 4.5.4 are Ok.

I'll bisect my 4.6.3 patch series to see which patch fixes it.

GCC 4.6.x miscompiling arm-linux?

[David Jander]

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

> David Jander writes:
>  > On Tue, 11 Sep 2012 13:35:40 +0200
>  > Mikael Pettersson <mikpe@it.uu.se> wrote:
>  > 
>  > > David Jander writes:
>  > >  > > 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 ;-)
>  > >  > 
>  > > ...
>  > >  > > 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....
>  > > 
>  > > And I'd like to confirm first. Please tell us the following:
>  > > 
>  > >  > >  > > 2: include the output of gcc -v which tells how that gcc was configured,
>  > 
>  > Using built-in specs.
>  > COLLECT_GCC=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3
>  > COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/libexec/gcc/arm-v5te-linux-gnueabi/4.6.3/lto-wrapper
>  > Target: arm-v5te-linux-gnueabi
>  > Configured with: /home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/build-cross/gcc-4.6.3/configure --target=arm-v5te-linux-gnueabi --with-sysroot=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3
>  > -glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-v5te-linux-gnueabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.1 --with-system-zlib --with-gmp=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te
>  > -linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --with-mpfr=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --prefix=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-shared --disable-libssp --enable-checking=release
>  > Thread model: posix
>  > gcc version 4.6.3 (OSELAS.Toolchain-2011.11.1)
>  > 
>  > >  > >  > > 3: give the exact set of gcc options used then compiling the test case.
>  > 
>  > If I type this in a terminal:
>  > 
>  > 
>  > $ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -
>  > 
>  > struct flexcan_regs {
>  >         unsigned int mcr;
>  >         unsigned int rxfgmask;
>  > };
>  > 
>  > #define flexcan_read(a) (*(volatile unsigned int *)(a))
>  > #define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))
>  > 
>  > int flexcan_chip_start(int ver, struct flexcan_regs *regs)
>  > {
>  >         flexcan_write(0, &regs->mcr);
>  > 
>  >         if (ver >= 10)
>  >                 flexcan_write(0, &regs->rxfgmask);
>  > 
>  >         return 0;
>  > }
>  > 
>  > 
>  > I get this output after hitting <CTRL-D>:
>  > 
>  >         .cpu arm926ej-s
>  >         .fpu softvfp
>  >         .eabi_attribute 20, 1
>  >         .eabi_attribute 21, 1
>  >         .eabi_attribute 23, 3
>  >         .eabi_attribute 24, 1
>  >         .eabi_attribute 25, 1
>  >         .eabi_attribute 26, 2
>  >         .eabi_attribute 30, 4
>  >         .eabi_attribute 18, 4
>  >         .file   ""
>  >         .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.3"
>  >         .section        .note.GNU-stack,"",%progbits
>  > 
>  > 
>  > Do you need more information?
> 
> No, I can reproduce the bug with vanilla gcc-4.6.3; vanilla 4.7.1 and 4.5.4 are Ok.
> 
> I'll bisect my 4.6.3 patch series to see which patch fixes it.

Great. Thanks a lot for your help so far. Looking forward to see what fixes
this issue. Are you implying that you will also file the bug (and possible
patch) with gcc.gnu.org, or do you prefer me to do that?

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Mikael Pettersson]

David Jander writes:
 > On Tue, 11 Sep 2012 14:53:35 +0200
 > Mikael Pettersson <mikpe@it.uu.se> wrote:
 > 
 > > David Jander writes:
 > >  > On Tue, 11 Sep 2012 13:35:40 +0200
 > >  > Mikael Pettersson <mikpe@it.uu.se> wrote:
 > >  > 
 > >  > > David Jander writes:
 > >  > >  > > 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 ;-)
 > >  > >  > 
 > >  > > ...
 > >  > >  > > 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....
 > >  > > 
 > >  > > And I'd like to confirm first. Please tell us the following:
 > >  > > 
 > >  > >  > >  > > 2: include the output of gcc -v which tells how that gcc was configured,
 > >  > 
 > >  > Using built-in specs.
 > >  > COLLECT_GCC=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3
 > >  > COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/libexec/gcc/arm-v5te-linux-gnueabi/4.6.3/lto-wrapper
 > >  > Target: arm-v5te-linux-gnueabi
 > >  > Configured with: /home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/build-cross/gcc-4.6.3/configure --target=arm-v5te-linux-gnueabi --with-sysroot=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3
 > >  > -glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-v5te-linux-gnueabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.1 --with-system-zlib --with-gmp=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te
 > >  > -linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --with-mpfr=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --prefix=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-shared --disable-libssp --enable-checking=release
 > >  > Thread model: posix
 > >  > gcc version 4.6.3 (OSELAS.Toolchain-2011.11.1)
 > >  > 
 > >  > >  > >  > > 3: give the exact set of gcc options used then compiling the test case.
 > >  > 
 > >  > If I type this in a terminal:
 > >  > 
 > >  > 
 > >  > $ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -
 > >  > 
 > >  > struct flexcan_regs {
 > >  >         unsigned int mcr;
 > >  >         unsigned int rxfgmask;
 > >  > };
 > >  > 
 > >  > #define flexcan_read(a) (*(volatile unsigned int *)(a))
 > >  > #define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))
 > >  > 
 > >  > int flexcan_chip_start(int ver, struct flexcan_regs *regs)
 > >  > {
 > >  >         flexcan_write(0, &regs->mcr);
 > >  > 
 > >  >         if (ver >= 10)
 > >  >                 flexcan_write(0, &regs->rxfgmask);
 > >  > 
 > >  >         return 0;
 > >  > }
 > >  > 
 > >  > 
 > >  > I get this output after hitting <CTRL-D>:
 > >  > 
 > >  >         .cpu arm926ej-s
 > >  >         .fpu softvfp
 > >  >         .eabi_attribute 20, 1
 > >  >         .eabi_attribute 21, 1
 > >  >         .eabi_attribute 23, 3
 > >  >         .eabi_attribute 24, 1
 > >  >         .eabi_attribute 25, 1
 > >  >         .eabi_attribute 26, 2
 > >  >         .eabi_attribute 30, 4
 > >  >         .eabi_attribute 18, 4
 > >  >         .file   ""
 > >  >         .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.3"
 > >  >         .section        .note.GNU-stack,"",%progbits
 > >  > 
 > >  > 
 > >  > Do you need more information?
 > > 
 > > No, I can reproduce the bug with vanilla gcc-4.6.3; vanilla 4.7.1 and 4.5.4 are Ok.
 > > 
 > > I'll bisect my 4.6.3 patch series to see which patch fixes it.
 > 
 > Great. Thanks a lot for your help so far. Looking forward to see what fixes
 > this issue. Are you implying that you will also file the bug (and possible
 > patch) with gcc.gnu.org, or do you prefer me to do that?

This is a known bug: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445>.
It was reported and fixed in gcc trunk on March 1 this year, but missed
the gcc-4.6.3 release made the same day (and frozen a week or so before),
and it hasn't been applied to gcc-4.6.4 branch yet either.

I've been using and testing the fix in my own gcc-4.6 branch since March 4
without regressions. I'm attaching my backport of the fix below.

I'll ping gcc upstream about getting this into gcc-4.6.4.

/Mikael

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gcc-4.6.3-pr52445.patch
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20120911/d7fc3996/attachment-0001.ksh>

GCC 4.6.x miscompiling arm-linux?

[David Jander]

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

> David Jander writes:
>  > On Tue, 11 Sep 2012 14:53:35 +0200
>  > Mikael Pettersson <mikpe@it.uu.se> wrote:
>  > 
>  > > David Jander writes:
>  > >  > On Tue, 11 Sep 2012 13:35:40 +0200
>  > >  > Mikael Pettersson <mikpe@it.uu.se> wrote:
>  > >  > 
>  > >  > > David Jander writes:
>  > >  > >  > > 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 ;-)
>  > >  > >  > 
>  > >  > > ...
>  > >  > >  > > 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....
>  > >  > > 
>  > >  > > And I'd like to confirm first. Please tell us the following:
>  > >  > > 
>  > >  > >  > >  > > 2: include the output of gcc -v which tells how that gcc was configured,
>  > >  > 
>  > >  > Using built-in specs.
>  > >  > COLLECT_GCC=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3
>  > >  > COLLECT_LTO_WRAPPER=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/libexec/gcc/arm-v5te-linux-gnueabi/4.6.3/lto-wrapper
>  > >  > Target: arm-v5te-linux-gnueabi
>  > >  > Configured with: /home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/build-cross/gcc-4.6.3/configure --target=arm-v5te-linux-gnueabi --with-sysroot=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3
>  > >  > -glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-arm-v5te-linux-gnueabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-2011.11.1 --with-system-zlib --with-gmp=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te
>  > >  > -linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --with-mpfr=/home/djander/ptxdist/OSELAS.Toolchain-2011.11.1/platform-arm-v5te-linux-gnueabi-gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/sysroot-host --prefix=/opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-shared --disable-libssp --enable-checking=release
>  > >  > Thread model: posix
>  > >  > gcc version 4.6.3 (OSELAS.Toolchain-2011.11.1)
>  > >  > 
>  > >  > >  > >  > > 3: give the exact set of gcc options used then compiling the test case.
>  > >  > 
>  > >  > If I type this in a terminal:
>  > >  > 
>  > >  > 
>  > >  > $ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -
>  > >  > 
>  > >  > struct flexcan_regs {
>  > >  >         unsigned int mcr;
>  > >  >         unsigned int rxfgmask;
>  > >  > };
>  > >  > 
>  > >  > #define flexcan_read(a) (*(volatile unsigned int *)(a))
>  > >  > #define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))
>  > >  > 
>  > >  > int flexcan_chip_start(int ver, struct flexcan_regs *regs)
>  > >  > {
>  > >  >         flexcan_write(0, &regs->mcr);
>  > >  > 
>  > >  >         if (ver >= 10)
>  > >  >                 flexcan_write(0, &regs->rxfgmask);
>  > >  > 
>  > >  >         return 0;
>  > >  > }
>  > >  > 
>  > >  > 
>  > >  > I get this output after hitting <CTRL-D>:
>  > >  > 
>  > >  >         .cpu arm926ej-s
>  > >  >         .fpu softvfp
>  > >  >         .eabi_attribute 20, 1
>  > >  >         .eabi_attribute 21, 1
>  > >  >         .eabi_attribute 23, 3
>  > >  >         .eabi_attribute 24, 1
>  > >  >         .eabi_attribute 25, 1
>  > >  >         .eabi_attribute 26, 2
>  > >  >         .eabi_attribute 30, 4
>  > >  >         .eabi_attribute 18, 4
>  > >  >         .file   ""
>  > >  >         .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.3"
>  > >  >         .section        .note.GNU-stack,"",%progbits
>  > >  > 
>  > >  > 
>  > >  > Do you need more information?
>  > > 
>  > > No, I can reproduce the bug with vanilla gcc-4.6.3; vanilla 4.7.1 and 4.5.4 are Ok.
>  > > 
>  > > I'll bisect my 4.6.3 patch series to see which patch fixes it.
>  > 
>  > Great. Thanks a lot for your help so far. Looking forward to see what fixes
>  > this issue. Are you implying that you will also file the bug (and possible
>  > patch) with gcc.gnu.org, or do you prefer me to do that?
> 
> This is a known bug: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52445>.
> It was reported and fixed in gcc trunk on March 1 this year, but missed
> the gcc-4.6.3 release made the same day (and frozen a week or so before),
> and it hasn't been applied to gcc-4.6.4 branch yet either.
> 
> I've been using and testing the fix in my own gcc-4.6 branch since March 4
> without regressions. I'm attaching my backport of the fix below.
> 
> I'll ping gcc upstream about getting this into gcc-4.6.4.

Thanks a lot for this patch.
I can confirm that the bug is gone, and no other problems have appeared so
far. Successfully recompiled kernel and the entire userspace (ptxdist) with
the patched toolchain, and all seems well.

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Sascha Hauer]

On Tue, Sep 11, 2012 at 09:27:53AM +0200, David Jander wrote:
> 
> Hi Matt,
> 
> >         @ 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

AFAIK our OSELAS/PTXdist Toolchains use Linaro patches, this would
explain why both have the same result.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

GCC 4.6.x miscompiling arm-linux?

[David Jander]

On Tue, 11 Sep 2012 10:48:53 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:

> On Tue, Sep 11, 2012 at 09:27:53AM +0200, David Jander wrote:
> > 
> > Hi Matt,
> > 
> > >         @ 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
> 
> AFAIK our OSELAS/PTXdist Toolchains use Linaro patches, this would
> explain why both have the same result.

It would indeed, if I had just used OSELAS as-is, but I didn't ;-)
I made a copy of
arm-v5te-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
and replaced the version string 4.6.2 with 4.6.3. AFAIK, this way PTXdist will
download pristine gcc-4.6.3 sources and not apply any patches, since there is
no directory named patches/gcc-4.6.3, right? Can I assume that I have an
unpatched version of gcc-4.6.3 then?

Btw, Here's what I get from it:

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.3"
        .section        .note.GNU-stack,"",%progbits

Wrong code.
See the version string? It is clearly not an existing OSELAS version.

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Michael Olbrich]

On Tue, Sep 11, 2012 at 11:31:39AM +0200, David Jander wrote:
> On Tue, 11 Sep 2012 10:48:53 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
> 
> > On Tue, Sep 11, 2012 at 09:27:53AM +0200, David Jander wrote:
> > > 
> > > Hi Matt,
> > > 
> > > >         @ 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
> > 
> > AFAIK our OSELAS/PTXdist Toolchains use Linaro patches, this would
> > explain why both have the same result.

No, OSELAS Toolchains only uses the Linaro GCC for Cortex-A8/-A9

> It would indeed, if I had just used OSELAS as-is, but I didn't ;-)
> I made a copy of
> arm-v5te-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
> and replaced the version string 4.6.2 with 4.6.3. AFAIK, this way PTXdist will
> download pristine gcc-4.6.3 sources and not apply any patches, since there is
> no directory named patches/gcc-4.6.3, right? Can I assume that I have an
> unpatched version of gcc-4.6.3 then?

Correct. This way you'll get gcc-4.6.3 without any patches.

> Btw, Here's what I get from it:
> 
> 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.3"
>         .section        .note.GNU-stack,"",%progbits

How can I reproduce this output? I'd like to test this with different
toolchain versions.

> Wrong code.
> See the version string? It is clearly not an existing OSELAS version.

Hmmm, so far it seems all tested gcc-4.6.x versions produce wrong code,
correct?

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

GCC 4.6.x miscompiling arm-linux?

[Matthew Leach]

Michael Olbrich <mol@pengutronix.de> writes:
>> Btw, Here's what I get from it:
>> 
>> 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.3"
>>         .section        .note.GNU-stack,"",%progbits
>
> How can I reproduce this output? I'd like to test this with different
> toolchain versions.

You can use this code fragment to produce the error:

/* Structure of the hardware registers */
struct flexcan_regs {
	unsigned int mcr;
	unsigned int rxfgmask;
};

#define flexcan_read(a) (*(volatile unsigned int *)(a))
#define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))

int flexcan_chip_start(int ver, struct flexcan_regs *regs)
{
	flexcan_write(0, &regs->mcr);

	if (ver >= 10)
		flexcan_write(0, &regs->rxfgmask);

	return 0;
}

Matt

GCC 4.6.x miscompiling arm-linux?

[David Jander]

On Tue, 11 Sep 2012 12:29:05 +0200
Michael Olbrich <mol@pengutronix.de> wrote:

> On Tue, Sep 11, 2012 at 11:31:39AM +0200, David Jander wrote:
> > On Tue, 11 Sep 2012 10:48:53 +0200
> > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > 
> > > On Tue, Sep 11, 2012 at 09:27:53AM +0200, David Jander wrote:
> > > > 
> > > > Hi Matt,
> > > > 
> > > > >         @ 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
> > > 
> > > AFAIK our OSELAS/PTXdist Toolchains use Linaro patches, this would
> > > explain why both have the same result.
> 
> No, OSELAS Toolchains only uses the Linaro GCC for Cortex-A8/-A9
> 
> > It would indeed, if I had just used OSELAS as-is, but I didn't ;-)
> > I made a copy of
> > arm-v5te-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
> > and replaced the version string 4.6.2 with 4.6.3. AFAIK, this way PTXdist will
> > download pristine gcc-4.6.3 sources and not apply any patches, since there is
> > no directory named patches/gcc-4.6.3, right? Can I assume that I have an
> > unpatched version of gcc-4.6.3 then?
> 
> Correct. This way you'll get gcc-4.6.3 without any patches.
> 
> > Btw, Here's what I get from it:
> > 
> > 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.3"
> >         .section        .note.GNU-stack,"",%progbits
> 
> How can I reproduce this output? I'd like to test this with different
> toolchain versions.

I basically do this:

$ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -

struct flexcan_regs {
        unsigned int mcr;
        unsigned int rxfgmask;
};

#define flexcan_read(a) (*(volatile unsigned int *)(a))
#define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))

int flexcan_chip_start(int ver, struct flexcan_regs *regs)
{
        flexcan_write(0, &regs->mcr);

        if (ver >= 10)
                flexcan_write(0, &regs->rxfgmask);

        return 0;
}

> > Wrong code.
> > See the version string? It is clearly not an existing OSELAS version.
> 
> Hmmm, so far it seems all tested gcc-4.6.x versions produce wrong code,
> correct?

Looks like that, yes.

Best regards,

-- 
David Jander
Protonic Holland.

GCC 4.6.x miscompiling arm-linux?

[Michael Olbrich]

On Tue, Sep 11, 2012 at 12:42:26PM +0200, David Jander wrote:
> On Tue, 11 Sep 2012 12:29:05 +0200
> Michael Olbrich <mol@pengutronix.de> wrote:
> 
> > On Tue, Sep 11, 2012 at 11:31:39AM +0200, David Jander wrote:
> > > On Tue, 11 Sep 2012 10:48:53 +0200
> > > Sascha Hauer <s.hauer@pengutronix.de> wrote:
> > > 
> > > > On Tue, Sep 11, 2012 at 09:27:53AM +0200, David Jander wrote:
> > > > > 
> > > > > Hi Matt,
> > > > > 
> > > > > >         @ 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
> > > > 
> > > > AFAIK our OSELAS/PTXdist Toolchains use Linaro patches, this would
> > > > explain why both have the same result.
> > 
> > No, OSELAS Toolchains only uses the Linaro GCC for Cortex-A8/-A9
> > 
> > > It would indeed, if I had just used OSELAS as-is, but I didn't ;-)
> > > I made a copy of
> > > arm-v5te-linux-gnueabi_gcc-4.6.2_glibc-2.14.1_binutils-2.21.1a_kernel-2.6.39-sanitized.ptxconfig
> > > and replaced the version string 4.6.2 with 4.6.3. AFAIK, this way PTXdist will
> > > download pristine gcc-4.6.3 sources and not apply any patches, since there is
> > > no directory named patches/gcc-4.6.3, right? Can I assume that I have an
> > > unpatched version of gcc-4.6.3 then?
> > 
> > Correct. This way you'll get gcc-4.6.3 without any patches.
> > 
> > > Btw, Here's what I get from it:
> > > 
> > > 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.3"
> > >         .section        .note.GNU-stack,"",%progbits
> > 
> > How can I reproduce this output? I'd like to test this with different
> > toolchain versions.
> 
> I basically do this:
> 
> $ /opt/OSELAS.Toolchain-2011.11.1/arm-v5te-linux-gnueabi/gcc-4.6.3-glibc-2.14.1-binutils-2.21.1a-kernel-2.6.39-sanitized/bin/arm-v5te-linux-gnueabi-gcc-4.6.3 -Os -S -o - -x c -
> 
> struct flexcan_regs {
>         unsigned int mcr;
>         unsigned int rxfgmask;
> };
> 
> #define flexcan_read(a) (*(volatile unsigned int *)(a))
> #define flexcan_write(v,a)      (*(volatile unsigned int *)(a) = (v))
> 
> int flexcan_chip_start(int ver, struct flexcan_regs *regs)
> {
>         flexcan_write(0, &regs->mcr);
> 
>         if (ver >= 10)
>                 flexcan_write(0, &regs->rxfgmask);
> 
>         return 0;
> }
> 
> > > Wrong code.
> > > See the version string? It is clearly not an existing OSELAS version.
> > 
> > Hmmm, so far it seems all tested gcc-4.6.x versions produce wrong code,
> > correct?
> 
> Looks like that, yes.

Including the Linaro gcc releases it seems. I rebuilt the toolchain with
Linaro GCC 4.6-2012.08 and the result is the same.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |