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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox