gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Arnd Bergmann]

On Friday 24 October 2014 03:30:06 Olof's autobuilder wrote:
> Here are the build results from automated periodic testing.
> 
> The tree being built was arm-soc, found at:
> 
> http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git (for-next or to-build branch)
> 
> Topmost commit:
> 
> 06c0773 [EXPERIMENTAL] try to get Linux to build with bare-metal toolchain

This appears to have fixed one problem but not the other:

> Build logs (stderr only) can be found at the following link (experimental):
> 
> http://arm-soc.lixom.net/buildlogs/arm-soc/v3.18-rc1-20-g06c0773/
> 
> 
> 	Runtime:		57m 11s
> 
> 	Passed:			129
> 	Failed:			0
> 
> 	Warnings:		2917
> 
> 	Section mismatches:	0
> 
> -------------------------------------------------------------------------------
> 
> Failed defconfigs:
> 
> -------------------------------------------------------------------------------
> 
> Errors:

All build errors are gone now, after passing -D__linux__. That is good.

>       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
>       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
>       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]

The warnings are completely unchanged, still 249 unique warnings involving size_t,
using this patch:

diff --git a/arch/arm/include/asm/types.h b/arch/arm/include/asm/types.h
index a53cdb8f068c..baaa8739b0bf 100644
--- a/arch/arm/include/asm/types.h
+++ b/arch/arm/include/asm/types.h
@@ -16,7 +16,7 @@
  * types, so 'linux/types.h' and 'stdint.h' can be safely included from the same
  * source file (provided that -ffreestanding is used).
  *
- *                    int32_t         uint32_t               uintptr_t
+ *                    int32_t         uint32_t/size_t        uintptr_t
  * bare metal GCC     long            unsigned long          unsigned int
  * glibc GCC          int             unsigned int           unsigned int
  * kernel             int             unsigned int           unsigned long
@@ -29,7 +29,12 @@
 
 #ifdef __UINT32_TYPE__
 #undef __UINT32_TYPE__
-#define __UINT32_TYPE__        unsigned int
+#define __UINT32_TYPE__                unsigned int
+#endif
+
+#ifdef __SIZE_TYPE__
+#undef __SIZE_TYPE__
+#define __SIZE_TYPE__          unsigned int
 #endif
 
 #ifdef __UINTPTR_TYPE__

	Arnd

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Russell King - ARM Linux]

On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
> On Friday 24 October 2014 03:30:06 Olof's autobuilder wrote:
> > Here are the build results from automated periodic testing.
> > 
> > The tree being built was arm-soc, found at:
> > 
> > http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git (for-next or to-build branch)
> > 
> > Topmost commit:
> > 
> > 06c0773 [EXPERIMENTAL] try to get Linux to build with bare-metal toolchain
> 
> This appears to have fixed one problem but not the other:
> 
> > Build logs (stderr only) can be found at the following link (experimental):
> > 
> > http://arm-soc.lixom.net/buildlogs/arm-soc/v3.18-rc1-20-g06c0773/
> > 
> > 
> > 	Runtime:		57m 11s
> > 
> > 	Passed:			129
> > 	Failed:			0
> > 
> > 	Warnings:		2917
> > 
> > 	Section mismatches:	0
> > 
> > -------------------------------------------------------------------------------
> > 
> > Failed defconfigs:
> > 
> > -------------------------------------------------------------------------------
> > 
> > Errors:
> 
> All build errors are gone now, after passing -D__linux__. That is good.
> 
> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
> 
> The warnings are completely unchanged, still 249 unique warnings involving size_t,
> using this patch:

That's probably because the compiler is expecting size_t to be typedef'd
to __SIZE_TYPE__ and isn't expecting anyone to change it.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Ard Biesheuvel]

On 24 October 2014 12:52, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
>> On Friday 24 October 2014 03:30:06 Olof's autobuilder wrote:
>> > Here are the build results from automated periodic testing.
>> >
>> > The tree being built was arm-soc, found at:
>> >
>> > http://git.kernel.org/cgit/linux/kernel/git/arm/arm-soc.git (for-next or to-build branch)
>> >
>> > Topmost commit:
>> >
>> > 06c0773 [EXPERIMENTAL] try to get Linux to build with bare-metal toolchain
>>
>> This appears to have fixed one problem but not the other:
>>
>> > Build logs (stderr only) can be found at the following link (experimental):
>> >
>> > http://arm-soc.lixom.net/buildlogs/arm-soc/v3.18-rc1-20-g06c0773/
>> >
>> >
>> >     Runtime:                57m 11s
>> >
>> >     Passed:                 129
>> >     Failed:                 0
>> >
>> >     Warnings:               2917
>> >
>> >     Section mismatches:     0
>> >
>> > -------------------------------------------------------------------------------
>> >
>> > Failed defconfigs:
>> >
>> > -------------------------------------------------------------------------------
>> >
>> > Errors:
>>
>> All build errors are gone now, after passing -D__linux__. That is good.
>>
>> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
>> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
>> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
>>
>> The warnings are completely unchanged, still 249 unique warnings involving size_t,
>> using this patch:
>
> That's probably because the compiler is expecting size_t to be typedef'd
> to __SIZE_TYPE__ and isn't expecting anyone to change it.
>

Indeed, I wouldn't expect the printf format validation code inside GCC
to care about the actual values of macros and typedefs.
Could someone dump the builtin #define's of that compiler? For
instance, my bare metal 4.9 BE GCC gives me

$ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
-E -dM - <<<"" |grep _TYPE__
#define __UINT_LEAST8_TYPE__ unsigned char
#define __SIG_ATOMIC_TYPE__ int
#define __UINTMAX_TYPE__ long long unsigned int
#define __INT_FAST16_TYPE__ int
#define __INT_FAST64_TYPE__ long long int
#define __UINT8_TYPE__ unsigned char
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define __SIZE_TYPE__ unsigned int
#define __INT8_TYPE__ signed char
#define __INT_LEAST16_TYPE__ short int
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __UINT_FAST16_TYPE__ unsigned int
#define __CHAR16_TYPE__ short unsigned int
#define __INT_LEAST64_TYPE__ long long int
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __INTPTR_TYPE__ int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ unsigned int
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT64_TYPE__ long long int
#define __WINT_TYPE__ unsigned int
#define __UINT_LEAST32_TYPE__ long unsigned int
#define __INT_LEAST32_TYPE__ long int
#define __UINT64_TYPE__ long long unsigned int
#define __INT_FAST8_TYPE__ int
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ long unsigned int
#define __INT32_TYPE__ long int
#define __INTMAX_TYPE__ long long int
#define __PTRDIFF_TYPE__ int
#define __UINT32_TYPE__ long unsigned int
#define __UINTPTR_TYPE__ unsigned int
#define __UINT_FAST8_TYPE__ unsigned int

What is surprising here is that __SIZE_TYPE__ is int not long. Could
we in fact be dealing with a 4.9 bare metal GCC bug here?

-- 
Ard.

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Arnd Bergmann]

On Friday 24 October 2014 12:59:40 Ard Biesheuvel wrote:
> On 24 October 2014 12:52, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
> >> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
> >>
> >> The warnings are completely unchanged, still 249 unique warnings involving size_t,
> >> using this patch:
> >
> > That's probably because the compiler is expecting size_t to be typedef'd
> > to __SIZE_TYPE__ and isn't expecting anyone to change it.
> >
> 
> Indeed, I wouldn't expect the printf format validation code inside GCC
> to care about the actual values of macros and typedefs.
> Could someone dump the builtin #define's of that compiler? For
> instance, my bare metal 4.9 BE GCC gives me
> 
> $ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
> -E -dM - <<<"" |grep _TYPE__
> #define __UINT_LEAST8_TYPE__ unsigned char
> #define __SIG_ATOMIC_TYPE__ int
> #define __UINTMAX_TYPE__ long long unsigned int
> #define __INT_FAST16_TYPE__ int
> #define __INT_FAST64_TYPE__ long long int
> #define __UINT8_TYPE__ unsigned char
> #define __INT_FAST32_TYPE__ int
> #define __UINT_LEAST16_TYPE__ short unsigned int
> #define __SIZE_TYPE__ unsigned int
> #define __INT8_TYPE__ signed char
> #define __INT_LEAST16_TYPE__ short int
> #define __UINT_LEAST64_TYPE__ long long unsigned int
> #define __UINT_FAST16_TYPE__ unsigned int
> #define __CHAR16_TYPE__ short unsigned int
> #define __INT_LEAST64_TYPE__ long long int
> #define __INT16_TYPE__ short int
> #define __INT_LEAST8_TYPE__ signed char
> #define __INTPTR_TYPE__ int
> #define __UINT16_TYPE__ short unsigned int
> #define __WCHAR_TYPE__ unsigned int
> #define __UINT_FAST64_TYPE__ long long unsigned int
> #define __INT64_TYPE__ long long int
> #define __WINT_TYPE__ unsigned int
> #define __UINT_LEAST32_TYPE__ long unsigned int
> #define __INT_LEAST32_TYPE__ long int
> #define __UINT64_TYPE__ long long unsigned int
> #define __INT_FAST8_TYPE__ int
> #define __UINT_FAST32_TYPE__ unsigned int
> #define __CHAR32_TYPE__ long unsigned int
> #define __INT32_TYPE__ long int
> #define __INTMAX_TYPE__ long long int
> #define __PTRDIFF_TYPE__ int
> #define __UINT32_TYPE__ long unsigned int
> #define __UINTPTR_TYPE__ unsigned int
> #define __UINT_FAST8_TYPE__ unsigned int
> 
> What is surprising here is that __SIZE_TYPE__ is int not long. Could
> we in fact be dealing with a 4.9 bare metal GCC bug here?

This is what I get on every arm gcc version on my system,
all glibc or uClibc targetted, compared to yours:

 #define __UINT_FAST64_TYPE__ long long unsigned int
 #define __INT64_TYPE__ long long int
 #define __WINT_TYPE__ unsigned int
-#define __UINT_LEAST32_TYPE__ long unsigned int
-#define __INT_LEAST32_TYPE__ long int
+#define __UINT_LEAST32_TYPE__ unsigned int
+#define __INT_LEAST32_TYPE__ int
 #define __UINT64_TYPE__ long long unsigned int
-#define __INT_FAST8_TYPE__ int
+#define __INT_FAST8_TYPE__ signed char
 #define __UINT_FAST32_TYPE__ unsigned int
-#define __CHAR32_TYPE__ long unsigned int
-#define __INT32_TYPE__ long int
+#define __CHAR32_TYPE__ unsigned int
+#define __INT32_TYPE__ int
 #define __INTMAX_TYPE__ long long int
 #define __PTRDIFF_TYPE__ int
-#define __UINT32_TYPE__ long unsigned int
+#define __UINT32_TYPE__ unsigned int
 #define __UINTPTR_TYPE__ unsigned int
-#define __UINT_FAST8_TYPE__ unsigned int
+#define __UINT_FAST8_TYPE__ unsigned char

	Arnd

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Ard Biesheuvel]

On 24 October 2014 13:37, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 October 2014 12:59:40 Ard Biesheuvel wrote:
>> On 24 October 2014 12:52, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>> > On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
>> >> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
>> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
>> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
>> >>
>> >> The warnings are completely unchanged, still 249 unique warnings involving size_t,
>> >> using this patch:
>> >
>> > That's probably because the compiler is expecting size_t to be typedef'd
>> > to __SIZE_TYPE__ and isn't expecting anyone to change it.
>> >
>>
>> Indeed, I wouldn't expect the printf format validation code inside GCC
>> to care about the actual values of macros and typedefs.
>> Could someone dump the builtin #define's of that compiler? For
>> instance, my bare metal 4.9 BE GCC gives me
>>
>> $ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
>> -E -dM - <<<"" |grep _TYPE__
>> #define __UINT_LEAST8_TYPE__ unsigned char
>> #define __SIG_ATOMIC_TYPE__ int
>> #define __UINTMAX_TYPE__ long long unsigned int
>> #define __INT_FAST16_TYPE__ int
>> #define __INT_FAST64_TYPE__ long long int
>> #define __UINT8_TYPE__ unsigned char
>> #define __INT_FAST32_TYPE__ int
>> #define __UINT_LEAST16_TYPE__ short unsigned int
>> #define __SIZE_TYPE__ unsigned int
>> #define __INT8_TYPE__ signed char
>> #define __INT_LEAST16_TYPE__ short int
>> #define __UINT_LEAST64_TYPE__ long long unsigned int
>> #define __UINT_FAST16_TYPE__ unsigned int
>> #define __CHAR16_TYPE__ short unsigned int
>> #define __INT_LEAST64_TYPE__ long long int
>> #define __INT16_TYPE__ short int
>> #define __INT_LEAST8_TYPE__ signed char
>> #define __INTPTR_TYPE__ int
>> #define __UINT16_TYPE__ short unsigned int
>> #define __WCHAR_TYPE__ unsigned int
>> #define __UINT_FAST64_TYPE__ long long unsigned int
>> #define __INT64_TYPE__ long long int
>> #define __WINT_TYPE__ unsigned int
>> #define __UINT_LEAST32_TYPE__ long unsigned int
>> #define __INT_LEAST32_TYPE__ long int
>> #define __UINT64_TYPE__ long long unsigned int
>> #define __INT_FAST8_TYPE__ int
>> #define __UINT_FAST32_TYPE__ unsigned int
>> #define __CHAR32_TYPE__ long unsigned int
>> #define __INT32_TYPE__ long int
>> #define __INTMAX_TYPE__ long long int
>> #define __PTRDIFF_TYPE__ int
>> #define __UINT32_TYPE__ long unsigned int
>> #define __UINTPTR_TYPE__ unsigned int
>> #define __UINT_FAST8_TYPE__ unsigned int
>>
>> What is surprising here is that __SIZE_TYPE__ is int not long. Could
>> we in fact be dealing with a 4.9 bare metal GCC bug here?
>
> This is what I get on every arm gcc version on my system,
> all glibc or uClibc targetted, compared to yours:
>
>  #define __UINT_FAST64_TYPE__ long long unsigned int
>  #define __INT64_TYPE__ long long int
>  #define __WINT_TYPE__ unsigned int
> -#define __UINT_LEAST32_TYPE__ long unsigned int
> -#define __INT_LEAST32_TYPE__ long int
> +#define __UINT_LEAST32_TYPE__ unsigned int
> +#define __INT_LEAST32_TYPE__ int
>  #define __UINT64_TYPE__ long long unsigned int
> -#define __INT_FAST8_TYPE__ int
> +#define __INT_FAST8_TYPE__ signed char
>  #define __UINT_FAST32_TYPE__ unsigned int
> -#define __CHAR32_TYPE__ long unsigned int
> -#define __INT32_TYPE__ long int
> +#define __CHAR32_TYPE__ unsigned int
> +#define __INT32_TYPE__ int
>  #define __INTMAX_TYPE__ long long int
>  #define __PTRDIFF_TYPE__ int
> -#define __UINT32_TYPE__ long unsigned int
> +#define __UINT32_TYPE__ unsigned int
>  #define __UINTPTR_TYPE__ unsigned int
> -#define __UINT_FAST8_TYPE__ unsigned int
> +#define __UINT_FAST8_TYPE__ unsigned char
>

So no __SiZE_TYPE__ then? That's surprising ...

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Arnd Bergmann]

On Friday 24 October 2014 13:50:05 Ard Biesheuvel wrote:
> On 24 October 2014 13:37, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 24 October 2014 12:59:40 Ard Biesheuvel wrote:
> >> On 24 October 2014 12:52, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
> >> >> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
> >> >>
> >> >> The warnings are completely unchanged, still 249 unique warnings involving size_t,
> >> >> using this patch:
> >> >
> >> > That's probably because the compiler is expecting size_t to be typedef'd
> >> > to __SIZE_TYPE__ and isn't expecting anyone to change it.
> >> >
> >>
> >> Indeed, I wouldn't expect the printf format validation code inside GCC
> >> to care about the actual values of macros and typedefs.
> >> Could someone dump the builtin #define's of that compiler? For
> >> instance, my bare metal 4.9 BE GCC gives me
> >>
> >> $ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
> >> -E -dM - <<<"" |grep _TYPE__
> >> #define __UINT_LEAST8_TYPE__ unsigned char
> >> #define __SIG_ATOMIC_TYPE__ int
> >> #define __UINTMAX_TYPE__ long long unsigned int
> >> #define __INT_FAST16_TYPE__ int
> >> #define __INT_FAST64_TYPE__ long long int
> >> #define __UINT8_TYPE__ unsigned char
> >> #define __INT_FAST32_TYPE__ int
> >> #define __UINT_LEAST16_TYPE__ short unsigned int
> >> #define __SIZE_TYPE__ unsigned int
> >> #define __INT8_TYPE__ signed char
> >> #define __INT_LEAST16_TYPE__ short int
> >> #define __UINT_LEAST64_TYPE__ long long unsigned int
> >> #define __UINT_FAST16_TYPE__ unsigned int
> >> #define __CHAR16_TYPE__ short unsigned int
> >> #define __INT_LEAST64_TYPE__ long long int
> >> #define __INT16_TYPE__ short int
> >> #define __INT_LEAST8_TYPE__ signed char
> >> #define __INTPTR_TYPE__ int
> >> #define __UINT16_TYPE__ short unsigned int
> >> #define __WCHAR_TYPE__ unsigned int
> >> #define __UINT_FAST64_TYPE__ long long unsigned int
> >> #define __INT64_TYPE__ long long int
> >> #define __WINT_TYPE__ unsigned int
> >> #define __UINT_LEAST32_TYPE__ long unsigned int
> >> #define __INT_LEAST32_TYPE__ long int
> >> #define __UINT64_TYPE__ long long unsigned int
> >> #define __INT_FAST8_TYPE__ int
> >> #define __UINT_FAST32_TYPE__ unsigned int
> >> #define __CHAR32_TYPE__ long unsigned int
> >> #define __INT32_TYPE__ long int
> >> #define __INTMAX_TYPE__ long long int
> >> #define __PTRDIFF_TYPE__ int
> >> #define __UINT32_TYPE__ long unsigned int
> >> #define __UINTPTR_TYPE__ unsigned int
> >> #define __UINT_FAST8_TYPE__ unsigned int
> >>
> >> What is surprising here is that __SIZE_TYPE__ is int not long. Could
> >> we in fact be dealing with a 4.9 bare metal GCC bug here?
> >
> > This is what I get on every arm gcc version on my system,
> > all glibc or uClibc targetted, compared to yours:
> >
> >  #define __UINT_FAST64_TYPE__ long long unsigned int
> >  #define __INT64_TYPE__ long long int
> >  #define __WINT_TYPE__ unsigned int
> > -#define __UINT_LEAST32_TYPE__ long unsigned int
> > -#define __INT_LEAST32_TYPE__ long int
> > +#define __UINT_LEAST32_TYPE__ unsigned int
> > +#define __INT_LEAST32_TYPE__ int
> >  #define __UINT64_TYPE__ long long unsigned int
> > -#define __INT_FAST8_TYPE__ int
> > +#define __INT_FAST8_TYPE__ signed char
> >  #define __UINT_FAST32_TYPE__ unsigned int
> > -#define __CHAR32_TYPE__ long unsigned int
> > -#define __INT32_TYPE__ long int
> > +#define __CHAR32_TYPE__ unsigned int
> > +#define __INT32_TYPE__ int
> >  #define __INTMAX_TYPE__ long long int
> >  #define __PTRDIFF_TYPE__ int
> > -#define __UINT32_TYPE__ long unsigned int
> > +#define __UINT32_TYPE__ unsigned int
> >  #define __UINTPTR_TYPE__ unsigned int
> > -#define __UINT_FAST8_TYPE__ unsigned int
> > +#define __UINT_FAST8_TYPE__ unsigned char
> >
> 
> So no __SiZE_TYPE__ then? That's surprising ...
> 

Sorry for being unclear here: this is only the diff between my version and
yours, so everything that is not listed above __UINT_FAST64_TYPE__ is the
same on both compilers.

	Arnd

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Ard Biesheuvel]

On 24 October 2014 15:27, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 October 2014 13:50:05 Ard Biesheuvel wrote:
>> On 24 October 2014 13:37, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Friday 24 October 2014 12:59:40 Ard Biesheuvel wrote:
>> >> On 24 October 2014 12:52, Russell King - ARM Linux
>> >> <linux@arm.linux.org.uk> wrote:
>> >> > On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
>> >> >> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
>> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
>> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
>> >> >>
>> >> >> The warnings are completely unchanged, still 249 unique warnings involving size_t,
>> >> >> using this patch:
>> >> >
>> >> > That's probably because the compiler is expecting size_t to be typedef'd
>> >> > to __SIZE_TYPE__ and isn't expecting anyone to change it.
>> >> >
>> >>
>> >> Indeed, I wouldn't expect the printf format validation code inside GCC
>> >> to care about the actual values of macros and typedefs.
>> >> Could someone dump the builtin #define's of that compiler? For
>> >> instance, my bare metal 4.9 BE GCC gives me
>> >>
>> >> $ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
>> >> -E -dM - <<<"" |grep _TYPE__
>> >> #define __UINT_LEAST8_TYPE__ unsigned char
>> >> #define __SIG_ATOMIC_TYPE__ int
>> >> #define __UINTMAX_TYPE__ long long unsigned int
>> >> #define __INT_FAST16_TYPE__ int
>> >> #define __INT_FAST64_TYPE__ long long int
>> >> #define __UINT8_TYPE__ unsigned char
>> >> #define __INT_FAST32_TYPE__ int
>> >> #define __UINT_LEAST16_TYPE__ short unsigned int
>> >> #define __SIZE_TYPE__ unsigned int
>> >> #define __INT8_TYPE__ signed char
>> >> #define __INT_LEAST16_TYPE__ short int
>> >> #define __UINT_LEAST64_TYPE__ long long unsigned int
>> >> #define __UINT_FAST16_TYPE__ unsigned int
>> >> #define __CHAR16_TYPE__ short unsigned int
>> >> #define __INT_LEAST64_TYPE__ long long int
>> >> #define __INT16_TYPE__ short int
>> >> #define __INT_LEAST8_TYPE__ signed char
>> >> #define __INTPTR_TYPE__ int
>> >> #define __UINT16_TYPE__ short unsigned int
>> >> #define __WCHAR_TYPE__ unsigned int
>> >> #define __UINT_FAST64_TYPE__ long long unsigned int
>> >> #define __INT64_TYPE__ long long int
>> >> #define __WINT_TYPE__ unsigned int
>> >> #define __UINT_LEAST32_TYPE__ long unsigned int
>> >> #define __INT_LEAST32_TYPE__ long int
>> >> #define __UINT64_TYPE__ long long unsigned int
>> >> #define __INT_FAST8_TYPE__ int
>> >> #define __UINT_FAST32_TYPE__ unsigned int
>> >> #define __CHAR32_TYPE__ long unsigned int
>> >> #define __INT32_TYPE__ long int
>> >> #define __INTMAX_TYPE__ long long int
>> >> #define __PTRDIFF_TYPE__ int
>> >> #define __UINT32_TYPE__ long unsigned int
>> >> #define __UINTPTR_TYPE__ unsigned int
>> >> #define __UINT_FAST8_TYPE__ unsigned int
>> >>
>> >> What is surprising here is that __SIZE_TYPE__ is int not long. Could
>> >> we in fact be dealing with a 4.9 bare metal GCC bug here?
>> >
>> > This is what I get on every arm gcc version on my system,
>> > all glibc or uClibc targetted, compared to yours:
>> >
>> >  #define __UINT_FAST64_TYPE__ long long unsigned int
>> >  #define __INT64_TYPE__ long long int
>> >  #define __WINT_TYPE__ unsigned int
>> > -#define __UINT_LEAST32_TYPE__ long unsigned int
>> > -#define __INT_LEAST32_TYPE__ long int
>> > +#define __UINT_LEAST32_TYPE__ unsigned int
>> > +#define __INT_LEAST32_TYPE__ int
>> >  #define __UINT64_TYPE__ long long unsigned int
>> > -#define __INT_FAST8_TYPE__ int
>> > +#define __INT_FAST8_TYPE__ signed char
>> >  #define __UINT_FAST32_TYPE__ unsigned int
>> > -#define __CHAR32_TYPE__ long unsigned int
>> > -#define __INT32_TYPE__ long int
>> > +#define __CHAR32_TYPE__ unsigned int
>> > +#define __INT32_TYPE__ int
>> >  #define __INTMAX_TYPE__ long long int
>> >  #define __PTRDIFF_TYPE__ int
>> > -#define __UINT32_TYPE__ long unsigned int
>> > +#define __UINT32_TYPE__ unsigned int
>> >  #define __UINTPTR_TYPE__ unsigned int
>> > -#define __UINT_FAST8_TYPE__ unsigned int
>> > +#define __UINT_FAST8_TYPE__ unsigned char
>> >
>>
>> So no __SiZE_TYPE__ then? That's surprising ...
>>
>
> Sorry for being unclear here: this is only the diff between my version and
> yours, so everything that is not listed above __UINT_FAST64_TYPE__ is the
> same on both compilers.
>

Ah, ok. So apparently, size_t is not ambiguous between bare metal and
glibc GCC, so we are looking at something else here.

-- 
Ard.

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Thierry Reding]

On Fri, Oct 24, 2014 at 03:41:48PM +0200, Ard Biesheuvel wrote:
> On 24 October 2014 15:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Friday 24 October 2014 13:50:05 Ard Biesheuvel wrote:
> >> On 24 October 2014 13:37, Arnd Bergmann <arnd@arndb.de> wrote:
> >> > On Friday 24 October 2014 12:59:40 Ard Biesheuvel wrote:
> >> >> On 24 October 2014 12:52, Russell King - ARM Linux
> >> >> <linux@arm.linux.org.uk> wrote:
> >> >> > On Fri, Oct 24, 2014 at 12:49:50PM +0200, Arnd Bergmann wrote:
> >> >> >> >       1 drivers/video/fbdev/sm501fb.c:245:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 8 has type 'size_t' [-Wformat=]
> >> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat=]
> >> >> >> >       1 mm/percpu.c:895:3: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat=]
> >> >> >>
> >> >> >> The warnings are completely unchanged, still 249 unique warnings involving size_t,
> >> >> >> using this patch:
> >> >> >
> >> >> > That's probably because the compiler is expecting size_t to be typedef'd
> >> >> > to __SIZE_TYPE__ and isn't expecting anyone to change it.
> >> >> >
> >> >>
> >> >> Indeed, I wouldn't expect the printf format validation code inside GCC
> >> >> to care about the actual values of macros and typedefs.
> >> >> Could someone dump the builtin #define's of that compiler? For
> >> >> instance, my bare metal 4.9 BE GCC gives me
> >> >>
> >> >> $ /usr/local/gcc-linaro-armeb-none-eabi-4.9-2014.06_linux/bin/armeb-none-eabi-gcc
> >> >> -E -dM - <<<"" |grep _TYPE__
> >> >> #define __UINT_LEAST8_TYPE__ unsigned char
> >> >> #define __SIG_ATOMIC_TYPE__ int
> >> >> #define __UINTMAX_TYPE__ long long unsigned int
> >> >> #define __INT_FAST16_TYPE__ int
> >> >> #define __INT_FAST64_TYPE__ long long int
> >> >> #define __UINT8_TYPE__ unsigned char
> >> >> #define __INT_FAST32_TYPE__ int
> >> >> #define __UINT_LEAST16_TYPE__ short unsigned int
> >> >> #define __SIZE_TYPE__ unsigned int
> >> >> #define __INT8_TYPE__ signed char
> >> >> #define __INT_LEAST16_TYPE__ short int
> >> >> #define __UINT_LEAST64_TYPE__ long long unsigned int
> >> >> #define __UINT_FAST16_TYPE__ unsigned int
> >> >> #define __CHAR16_TYPE__ short unsigned int
> >> >> #define __INT_LEAST64_TYPE__ long long int
> >> >> #define __INT16_TYPE__ short int
> >> >> #define __INT_LEAST8_TYPE__ signed char
> >> >> #define __INTPTR_TYPE__ int
> >> >> #define __UINT16_TYPE__ short unsigned int
> >> >> #define __WCHAR_TYPE__ unsigned int
> >> >> #define __UINT_FAST64_TYPE__ long long unsigned int
> >> >> #define __INT64_TYPE__ long long int
> >> >> #define __WINT_TYPE__ unsigned int
> >> >> #define __UINT_LEAST32_TYPE__ long unsigned int
> >> >> #define __INT_LEAST32_TYPE__ long int
> >> >> #define __UINT64_TYPE__ long long unsigned int
> >> >> #define __INT_FAST8_TYPE__ int
> >> >> #define __UINT_FAST32_TYPE__ unsigned int
> >> >> #define __CHAR32_TYPE__ long unsigned int
> >> >> #define __INT32_TYPE__ long int
> >> >> #define __INTMAX_TYPE__ long long int
> >> >> #define __PTRDIFF_TYPE__ int
> >> >> #define __UINT32_TYPE__ long unsigned int
> >> >> #define __UINTPTR_TYPE__ unsigned int
> >> >> #define __UINT_FAST8_TYPE__ unsigned int
> >> >>
> >> >> What is surprising here is that __SIZE_TYPE__ is int not long. Could
> >> >> we in fact be dealing with a 4.9 bare metal GCC bug here?
> >> >
> >> > This is what I get on every arm gcc version on my system,
> >> > all glibc or uClibc targetted, compared to yours:
> >> >
> >> >  #define __UINT_FAST64_TYPE__ long long unsigned int
> >> >  #define __INT64_TYPE__ long long int
> >> >  #define __WINT_TYPE__ unsigned int
> >> > -#define __UINT_LEAST32_TYPE__ long unsigned int
> >> > -#define __INT_LEAST32_TYPE__ long int
> >> > +#define __UINT_LEAST32_TYPE__ unsigned int
> >> > +#define __INT_LEAST32_TYPE__ int
> >> >  #define __UINT64_TYPE__ long long unsigned int
> >> > -#define __INT_FAST8_TYPE__ int
> >> > +#define __INT_FAST8_TYPE__ signed char
> >> >  #define __UINT_FAST32_TYPE__ unsigned int
> >> > -#define __CHAR32_TYPE__ long unsigned int
> >> > -#define __INT32_TYPE__ long int
> >> > +#define __CHAR32_TYPE__ unsigned int
> >> > +#define __INT32_TYPE__ int
> >> >  #define __INTMAX_TYPE__ long long int
> >> >  #define __PTRDIFF_TYPE__ int
> >> > -#define __UINT32_TYPE__ long unsigned int
> >> > +#define __UINT32_TYPE__ unsigned int
> >> >  #define __UINTPTR_TYPE__ unsigned int
> >> > -#define __UINT_FAST8_TYPE__ unsigned int
> >> > +#define __UINT_FAST8_TYPE__ unsigned char
> >> >
> >>
> >> So no __SiZE_TYPE__ then? That's surprising ...
> >>
> >
> > Sorry for being unclear here: this is only the diff between my version and
> > yours, so everything that is not listed above __UINT_FAST64_TYPE__ is the
> > same on both compilers.
> >
> 
> Ah, ok. So apparently, size_t is not ambiguous between bare metal and
> glibc GCC, so we are looking at something else here.

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?

Thierry
-------------- 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/4058cb8f/attachment.sig>

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Arnd Bergmann]

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.

	Arnd

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Thierry Reding]

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>

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Ard Biesheuvel]

On 6 November 2014 13:59, Thierry Reding <thierry.reding@gmail.com> wrote:
> 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.
>

Yes, that is what it looks like.

> 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

The mystery is that arm-linux-gnueabihf-gcc does not produce the
warning, whereas Olof's arm-none-eabi-gcc does (built from the same
source version, as far as we can tell)

> 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.
>

I have tried this with the BE bare metal compiler I have on my system,
and it did not produce a warning.
(gcc-linaro-armeb-none-eabi-4.9-2014.06)

-- 
Ard.

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Thierry Reding]

On Thu, Nov 06, 2014 at 02:08:37PM +0100, Ard Biesheuvel wrote:
> On 6 November 2014 13:59, Thierry Reding <thierry.reding@gmail.com> wrote:
> > 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.
> >
> 
> Yes, that is what it looks like.
> 
> > 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
> 
> The mystery is that arm-linux-gnueabihf-gcc does not produce the
> warning, whereas Olof's arm-none-eabi-gcc does (built from the same
> source version, as far as we can tell)
> 
> > 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.
> >
> 
> I have tried this with the BE bare metal compiler I have on my system,
> and it did not produce a warning.
> (gcc-linaro-armeb-none-eabi-4.9-2014.06)

Interesting. Can you still reproduce the build warnings from Olof's logs
if you run that compiler on the kernel? It'd be nice to trigger this in
a minimal test case since it seems to be something that needs to be
fixed in GCC.

Thierry
-------------- 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/5a5a8355/attachment.sig>

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Arnd Bergmann]

On Thursday 06 November 2014 14:08:37 Ard Biesheuvel wrote:
> On 6 November 2014 13:59, Thierry Reding <thierry.reding@gmail.com> wrote:
> > 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.
> >
> 
> Yes, that is what it looks like.

My reading is different, given this comment:

  /* If ARG_TYPE is a typedef with a misleading name (for example,
     size_t but not the standard size_t expected by printf %zu), avoid
     printing the typedef name.  */

I think what happens is that %z accepts size_t only when it is
defined to the right type, but prints a message with the raw
scalar type if the typedef does not match what %z expects.

> > 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
> 
> The mystery is that arm-linux-gnueabihf-gcc does not produce the
> warning, whereas Olof's arm-none-eabi-gcc does (built from the same
> source version, as far as we can tell)

Right, and as Russell pointed out, that compiler has other issues
as well: the size of 'enum' is different and it does not define the
__linux__ macro.

	Arnd

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Russell King - ARM Linux]

On Thu, Nov 06, 2014 at 12:49:22PM +0100, Thierry Reding wrote:
> On Fri, Oct 24, 2014 at 03:41:48PM +0200, Ard Biesheuvel wrote:
> > Ah, ok. So apparently, size_t is not ambiguous between bare metal and
> > glibc GCC, so we are looking at something else here.
> 
> 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?

We haven't been mucking with the size_t typedef.  We've been trying to
find out /why/ GCC 4.9 complains.

For the n'th time, what we know is:

- gcc 4.9 bare metal seems to define __SIZE_TYPE__ to be unsigned int.
- gcc 4.9's stddef.h typedef's size_t to __SIZE_TYPE__.
- therefore, size_t is typedef'd from unsigned int.
- the kernel typedefs __kernel_size_t from unsigned int.
- the kernel typedefs size_t from __kernel_size_t.

So, in theory, size_t in the kernel is unsigned int too.  However, GCC 4.9
issues loads of complains when %zu or %zd is used with a size_t variable
in the kernel.

The question that we've been trying to work out is... why is this?  Right
now, it seems no one has an answer for this question.  We don't know
whether it's a compiler bug or not - and Arnd has explained why not.

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

gcc 4.9 build warnings (was: Re: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))

[Mark Brown]

On Thu, Nov 06, 2014 at 01:28:28PM +0000, Russell King - ARM Linux wrote:

> For the n'th time, what we know is:

> - gcc 4.9 bare metal seems to define __SIZE_TYPE__ to be unsigned int.
> - gcc 4.9's stddef.h typedef's size_t to __SIZE_TYPE__.
> - therefore, size_t is typedef'd from unsigned int.
> - the kernel typedefs __kernel_size_t from unsigned int.
> - the kernel typedefs size_t from __kernel_size_t.

> So, in theory, size_t in the kernel is unsigned int too.  However, GCC 4.9
> issues loads of complains when %zu or %zd is used with a size_t variable
> in the kernel.

> The question that we've been trying to work out is... why is this?  Right
> now, it seems no one has an answer for this question.  We don't know
> whether it's a compiler bug or not - and Arnd has explained why not.

Isn't this GCC tracking the literal use of size_t in addition to the
actual definition and warning based on that information for the size_t
specific formatting.  Seems weird that it'd only affect a freestanding
build though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141106/8d8167a2/attachment.sig>