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: Thu, 23 Oct 2014 17:33:52 +0200 [thread overview]
Message-ID: <5876859.V209eoUfHk@wuerfel> (raw)
In-Reply-To: <20141023141415.GJ27405@n2100.arm.linux.org.uk>
On Thursday 23 October 2014 15:14:15 Russell King - ARM Linux wrote:
> On Thu, Oct 23, 2014 at 03:57:44PM +0200, Arnd Bergmann wrote:
> > On Wednesday 22 October 2014 23:38:45 Russell King - ARM Linux wrote:
> > > So, size_t is typedef'd as "unsigned int" - and indeed, the compiler thinks
> > > that size_t is "unsigned int". But it doesn't seem to like the use of the
> > > 'z' flag in the printf format string with size_t.
> > >
> > > Any ideas what's going on here? Does gcc 4.9 stddef.h define size_t
> > > differently?
> >
> > This may be a related issue to the first one. Maybe the linux toolchain uses
> > a different type from the generic toolchain.
>
> Please re-read.
>
> Olof's 4.9 toolchain is the one which spat out these errors.
>
> Olof's 4.9 toolchain defines __SIZE_TYPE__ to "unsigned int". I asked
> Olof to verify this via:
>
> $ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -
>
> which Olof said produces "unsigned int".
>
> Userspace typedefs size_t to __SIZE_TYPE__ which is "unsigned int". Ergo,
> in userspace, size_t is typedef'd from "unsigned int".
>
> The kernel typedefs __kernel_size_t to "unsigned int", which is then
> used to typedef the kernel size_t to __kernel_size_t. Ergo, size_t in
> the kernel is "unsigned int".
>
> In the kernel, passing a variable with type size_t to a format with
> "%zu", results in Olof's 4.9 toolchain complaining that the format
> takes a size_t type, but GCC claims the variable passed was of type
> "unsigned int" not "size_t".
I was thinking of the case where gcc's internal code for printf format
checking doesn't match the definition of size_t. It's possible that this
is different from the type that is defined in stddef.h.
FWIW, the stddef.h that comes with my gcc-4.9 contains
#define __SIZE_TYPE__ long unsigned int
but the command
$ echo __SIZE_TYPE__ | arm-linux-gcc -E -o - -xc -
also returns "unsigned int" when running through the compiler that
comes with this header.
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.
Arnd
next prev parent reply other threads:[~2014-10-23 15:33 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 [this message]
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
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=5876859.V209eoUfHk@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