From: Arnd Bergmann <arnd@arndb.de>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
arcml <linux-snps-arc@lists.infradead.org>,
Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com>
Subject: Re: [PATCH] lpfc: use %zd format string for size_t
Date: Fri, 28 Oct 2016 23:33:45 +0200 [thread overview]
Message-ID: <18294392.WY3416IpNg@wuerfel> (raw)
In-Reply-To: <26e675e3-af5b-eaf7-fea0-b4aff9767332@synopsys.com>
On Friday, October 28, 2016 2:03:21 PM CEST Vineet Gupta wrote:
>
> I'm trying to use about to be released ARC gcc 6.x with current kernels and see a
> flood of warnings due to these legit fixes - i.e.g arc gcc 6.2 complains when it
> sees -zx formats.
>
> CC mm/percpu.o
> ../mm/percpu.c: In function ‘pcpu_alloc’:
> ../mm/percpu.c:890:14: warning: format ‘%zu’ expects argument of type ‘size_t’,
> but argument 4 has type ‘unsigned int’ [-Wformat=]
> WARN(true, "illegal size (%zu) or align (%zu) for percpu allocation\n",
>
> I'm not sure what is going on since the data type is size_t alright - although
> from posix_types.h is
>
> typedef unsigned int __kernel_size_t;
> typedef __kernel_size_t size_t;
>
> And this seems to be same for ARC as well as ARM. I tried ARM gcc 6.1 @
> https://snapshots.linaro.org/components/toolchain/binaries/6.1-2016.08-rc1/arm-linux-gnueabihf/
>
> which doesn't seem to be complaining.
>
> With V=1, I checked the respective ARM and ARC toggles in play, but nothing
> related to this seems to be standing out.
>
> I know this is more of a question to our GNU folks, but was wondering if you had
> more insight into it - which you almost always do
I've seen the problem you describe before, but I don't remember the
exact details. I think what happened is that the compiler knows
what type size_t is supposed to be, either unsigned int or unsigned
long, regardless of what our kernel headers say it is.
This is configuration specific, and something caused your compiler to
be built assuming that size_t is unsigned long, while the kernel
headers are assuming it should be unsigned int.
You can try overriding __kernel_size_t in your asm/posix_types.h
to define it as unsigned long, or try to build your compiler
to match the kernel headers, but the first step would be to find
out why the compiler changed in the first place, assuming that older
compiler versions were matching the kernel here.
Arnd
next prev parent reply other threads:[~2016-10-28 21:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 12:35 Arnd Bergmann
2016-10-17 13:39 ` Johannes Thumshirn
2016-10-17 15:53 ` James Smart
2016-10-17 17:59 ` Martin K. Petersen
2016-10-28 21:03 ` Vineet Gupta
2016-10-28 21:33 ` Arnd Bergmann [this message]
2016-10-28 21:44 ` Vineet Gupta
2016-10-28 21:48 ` Arnd Bergmann
2016-10-28 21:52 ` Vineet Gupta
2016-10-28 21:58 ` Vineet Gupta
2016-10-28 22:03 ` Arnd Bergmann
2016-10-28 23:16 ` Vineet Gupta
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=18294392.WY3416IpNg@wuerfel \
--to=arnd@arndb.de \
--cc=Claudiu.Zissulescu@synopsys.com \
--cc=Vineet.Gupta1@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@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
all inboxes | Powered by JetHome®