From: thierry.reding@gmail.com (Thierry Reding)
To: linux-arm-kernel@lists.infradead.org
Subject: gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))
Date: Thu, 6 Nov 2014 13:59:00 +0100 [thread overview]
Message-ID: <20141106125857.GA12260@ulmo> (raw)
In-Reply-To: <2700572.p8cKrIiMH5@wuerfel>
On Thu, Nov 06, 2014 at 12:56:27PM +0100, Arnd Bergmann wrote:
> On Thursday 06 November 2014 12:49:22 Thierry Reding wrote:
> > GCC complains about the format specifier being wrong. %zu/%zd are the
> > correct specifiers for variables of type size_t/ssize_t, so wherever a
> > size_t or ssize_t is used as parameter it should have a corresponding
> > %zu or %zd specifier.
> >
> > Why not just fix it properly instead of mucking about with the size_t
> > typedef?
> >
>
> Yes, but where are %zu and %zd implemented in gcc? I've looked but
> couldn't find it. For all I can tell is that gcc's own interpretation
> of %z doesn't match its definition of __SIZE_TYPE__ when building for
> bare-metal.
I think the code you're looking for is gcc/c-family/c-format.c in
function format_type_warning() (and its callers). Now my understanding
of GCC internals is fairly limited, but what I think is happening is
that the matching happens on the exact typedef, so even if size_t is
typedef'd to unsigned int and the argument is of type unsigned int the
check will still fail and cause the warning.
Interestingly I can't seem to reproduce these warnings, neither with the
native compiler on my system nor a 4.9.0 ARM cross-compiler. I've used
the attached source file as a test case (derived from the code at line
1244 in drivers/regmap/regmap.c, which causes the warning in one of your
logs). Can you verify that the same warning happens when you run your
compiler on that? I've tried compiling with something like this:
$ gcc -Wall -Wextra -Wformat=2 -c test.c
I don't think all of these are necessary, plain -Wformat /should/ be
enough.
It's weird because both operands of the division are size_t, so I'm
guessing the compiler looses the type information at some point.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-c
Size: 126 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141106/afcf7781/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141106/afcf7781/attachment-0001.sig>
next prev parent reply other threads:[~2014-11-06 12:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <544a2a2e.a2db440a.6eeb.ffffaef3@mx.google.com>
2014-10-24 10:49 ` gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773)) Arnd Bergmann
2014-10-24 10:52 ` Russell King - ARM Linux
2014-10-24 10:59 ` Ard Biesheuvel
2014-10-24 11:37 ` Arnd Bergmann
2014-10-24 11:50 ` Ard Biesheuvel
2014-10-24 13:27 ` Arnd Bergmann
2014-10-24 13:41 ` Ard Biesheuvel
2014-11-06 11:49 ` Thierry Reding
2014-11-06 11:56 ` Arnd Bergmann
2014-11-06 12:59 ` Thierry Reding [this message]
2014-11-06 13:08 ` Ard Biesheuvel
2014-11-06 13:16 ` Thierry Reding
2014-11-06 13:20 ` Arnd Bergmann
2014-11-06 13:28 ` Russell King - ARM Linux
2014-11-06 13:58 ` Mark Brown
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=20141106125857.GA12260@ulmo \
--to=thierry.reding@gmail.com \
--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.