public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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

  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