From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))
Date: Fri, 24 Oct 2014 11:13:27 +0200 [thread overview]
Message-ID: <13842628.d0ipOeqpYt@wuerfel> (raw)
In-Reply-To: <CAOesGMh3ivsvrXpKj7J8tbSXnXutXJdkfm=sbo0j_eJVAQgFsg@mail.gmail.com>
On Thursday 23 October 2014 13:33:13 Olof Johansson wrote:
> On Thu, Oct 23, 2014 at 1:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Thursday 23 October 2014 17:12:20 Russell King - ARM Linux wrote:
> >>
> >> > I haven't found the code in gcc that performs the type check for
> >> > printf, but I've found a comment about that code intentionally
> >> > resolving the type (printing 'unsigned int') when the typedef
> >> > does not match the expected type.
> >>
> >> If I had a copy of the GCC 4.9 source locally, I'd dig into it too and
> >> try to work out what's going on. My gut feeling is that it's a bug in
> >> GCC rather than something which the kernel is doing wrong.
> >>
> >
> > I suspect it has something to do with the way that Olof's gcc is built,
> > since it doesn't happen for me using the same kernel source and gcc-4.9.1
> > or 4.10-prerelease.
>
> Mine is a 4.9.1 built with segher's buildall scripts.
>
Ok, that also explains the problems with the missing __linux__ macro, given
Ard's reply about bare-metal gcc.
I think we have two choices here:
a) change the buildall script so it actually builds a compiler that behaves
in the way we expect for the kernel (__SIZE_TYPE__ and __linux__ at least,
possibly others)
b) change the kernel to work with the way the bare-metal compiler is built,
adding -D__linux__ in the ARM Makefile and applying Ard's workaround for
__SIZE_TYPE__/__INT32_TYPE__/__UINT32_TYPE__/__UINTPTR_TYPE__.
Both options are a little hacky and I don't really like them, but I think
it makes sense to do one of them.
Arnd
next prev parent reply other threads:[~2014-10-24 9:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5447442c.a9ca440a.2060.5e09@mx.google.com>
2014-10-22 22:38 ` gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022)) Russell King - ARM Linux
2014-10-23 13:57 ` Arnd Bergmann
2014-10-23 14:14 ` Russell King - ARM Linux
2014-10-23 15:33 ` Arnd Bergmann
2014-10-23 16:12 ` Russell King - ARM Linux
2014-10-23 20:31 ` Arnd Bergmann
2014-10-23 20:33 ` Olof Johansson
2014-10-24 9:13 ` Arnd Bergmann [this message]
2014-10-24 9:34 ` Arnd Bergmann
2014-10-24 9:44 ` Russell King - ARM Linux
2014-10-24 10:27 ` Arnd Bergmann
2014-10-24 18:25 ` Segher Boessenkool
2014-10-24 18:33 ` Russell King - ARM Linux
2014-10-24 21:47 ` Olof Johansson
2014-11-11 21:32 ` Arnd Bergmann
2014-11-12 1:34 ` Olof Johansson
2014-11-12 10:48 ` Russell King - ARM Linux
2014-11-13 14:19 ` Segher Boessenkool
2014-11-13 14:30 ` Arnd Bergmann
2014-10-23 22:03 ` Ard Biesheuvel
2014-10-23 22:26 ` Russell King - ARM Linux
2014-10-24 21:47 ` Olof Johansson
2014-10-24 21:56 ` Russell King - ARM Linux
2014-10-24 22:22 ` Olof Johansson
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=13842628.d0ipOeqpYt@wuerfel \
--to=arnd@arndb.de \
--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.