Linux-ARM-Kernel Archive on lore.kernel.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: arm-soc build: 2917 warnings 0 failures (arm-soc/v3.18-rc1-20-g06c0773))
Date: Fri, 24 Oct 2014 13:37:19 +0200	[thread overview]
Message-ID: <1847682.hInUtg9rQz@wuerfel> (raw)
In-Reply-To: <CAKv+Gu_bvO0mPCX6nT+Po_YnNsLHmrCArbaOSYV6ruRJ0NQ14w@mail.gmail.com>

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

  reply	other threads:[~2014-10-24 11:37 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 [this message]
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
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=1847682.hInUtg9rQz@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