From: Vineet.Gupta1@synopsys.com (Vineet Gupta)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] lpfc: use %zd format string for size_t
Date: Fri, 28 Oct 2016 14:44:13 -0700 [thread overview]
Message-ID: <27a8ca4b-3259-17bd-acbf-ee809ec4f67b@synopsys.com> (raw)
In-Reply-To: <18294392.WY3416IpNg@wuerfel>
On 10/28/2016 02:33 PM, Arnd Bergmann wrote:
> 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,
Indeed if I hack include/linux/types.h
-typedef __kernel_size_t size_t;
+typedef unsigned long size_t;
then the warning goes away, so gcc is indeed assuming size_t to be unsigned long
and not unsigned int. That helps a lot.
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
WARNING: multiple messages have this Message-ID (diff)
From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: arcml <linux-snps-arc@lists.infradead.org>,
lkml <linux-kernel@vger.kernel.org>,
Claudiu Zissulescu <Claudiu.Zissulescu@synopsys.com>
Subject: Re: [PATCH] lpfc: use %zd format string for size_t
Date: Fri, 28 Oct 2016 14:44:13 -0700 [thread overview]
Message-ID: <27a8ca4b-3259-17bd-acbf-ee809ec4f67b@synopsys.com> (raw)
In-Reply-To: <18294392.WY3416IpNg@wuerfel>
On 10/28/2016 02:33 PM, Arnd Bergmann wrote:
> 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,
Indeed if I hack include/linux/types.h
-typedef __kernel_size_t size_t;
+typedef unsigned long size_t;
then the warning goes away, so gcc is indeed assuming size_t to be unsigned long
and not unsigned int. That helps a lot.
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:44 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 12:35 [PATCH] lpfc: use %zd format string for size_t 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:03 ` Vineet Gupta
2016-10-28 21:33 ` Arnd Bergmann
2016-10-28 21:33 ` Arnd Bergmann
2016-10-28 21:44 ` Vineet Gupta [this message]
2016-10-28 21:44 ` Vineet Gupta
2016-10-28 21:48 ` Arnd Bergmann
2016-10-28 21:48 ` Arnd Bergmann
2016-10-28 21:52 ` Vineet Gupta
2016-10-28 21:52 ` Vineet Gupta
2016-10-28 21:58 ` Vineet Gupta
2016-10-28 21:58 ` Vineet Gupta
2016-10-28 22:03 ` Arnd Bergmann
2016-10-28 22:03 ` Arnd Bergmann
2016-10-28 23:16 ` Vineet Gupta
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=27a8ca4b-3259-17bd-acbf-ee809ec4f67b@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--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 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.