gcc 4.9 build warnings (was: Re: next build: 2674 warnings 1 failures (next/next-20141022))
Russell King - ARM Linux
linux at arm.linux.org.uk
Thu Oct 23 07:14:15 PDT 2014
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".
Why?
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
More information about the linux-arm-kernel
mailing list