All of lore.kernel.org
 help / color / mirror / Atom feed
From: david.jander@protonic.nl (David Jander)
To: linux-arm-kernel@lists.infradead.org
Subject: GCC 4.6.x miscompiling arm-linux?
Date: Tue, 11 Sep 2012 12:42:26 +0200	[thread overview]
Message-ID: <20120911124226.27fa248b@archvile> (raw)
In-Reply-To: <20120911102905.GC14994@pengutronix.de>

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.

  parent reply	other threads:[~2012-09-11 10:42 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-10 15:16 GCC 4.6.x miscompiling arm-linux? David Jander
2012-09-10 17:11 ` Matthew Leach
2012-09-11  7:27   ` David Jander
2012-09-11  7:54     ` David Jander
2012-09-11  8:11     ` Mikael Pettersson
2012-09-11  8:49       ` David Jander
2012-09-11  9:41         ` Mikael Pettersson
2012-09-11 10:37           ` David Jander
2012-09-11 11:35             ` Mikael Pettersson
2012-09-11 11:52               ` David Jander
2012-09-11 12:53                 ` Mikael Pettersson
2012-09-11 13:43                   ` David Jander
2012-09-11 14:10                     ` Mikael Pettersson
2012-09-13  8:38                       ` David Jander
2012-09-11  8:48     ` Sascha Hauer
2012-09-11  9:31       ` David Jander
2012-09-11 10:29         ` Michael Olbrich
2012-09-11 10:33           ` Matthew Leach
2012-09-11 10:42           ` David Jander [this message]
2012-09-11 13:07             ` Michael Olbrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120911124226.27fa248b@archvile \
    --to=david.jander@protonic.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.