From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 20 Jun 2014 11:45:18 -0400 Subject: [U-Boot] m68k: Fix warnings with gcc 4.6 In-Reply-To: References: <1402200478-14055-1-git-send-email-sjg@chromium.org> <20140611221928.GO7841@bill-the-cat> <20140617173448.E7F1.AA925319@jp.panasonic.com> <20140618175334.GE26243@bill-the-cat> Message-ID: <20140620154518.GI20480@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Jun 19, 2014 at 05:33:44PM -0600, Simon Glass wrote: > Hi Tom, > > On 18 June 2014 11:53, Tom Rini wrote: > > On Tue, Jun 17, 2014 at 08:52:09PM -0700, Simon Glass wrote: > >> Hi Masahiro, > >> > >> On 17 June 2014 01:34, Masahiro Yamada wrote: > >> > Hi Simon, > >> > > >> > > >> > On Wed, 11 Jun 2014 18:19:28 -0400 > >> > Tom Rini wrote: > >> > > >> >> On Sat, Jun 07, 2014 at 10:07:58PM -0600, Simon Glass wrote: > >> >> > >> >> > Most of the warnings seem to be related to using 'int' for size_t. Change > >> >> > this and fix up the remaining warnings and problems. For bootm, the warning > >> >> > was masked by others, and there is an actual bug in the code. > >> >> > > >> >> > Signed-off-by: Simon Glass > >> >> > >> >> Applied to u-boot/master, thanks! > >> >> > >> >> -- > >> >> Tom > >> > > >> > > >> > > >> > Since commit ddc94378d, I see lots of warnings when compiling m68k boards like this: > >> > > >> > > >> > > >> > > >> > Configuring for M52277EVB - Board: M52277EVB, Options: SYS_SPANSION_BOOT,SYS_TEXT_BASE=0x00000000 > >> > text data bss dec hex filename > >> > 117375 11530 4092 132997 20785 ./u-boot > >> > common/cli_simple.c: In function 'process_macros': > >> > common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] > >> > common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] > >> > drivers/mtd/spi/sf.c: In function 'spi_flash_read_write': > >> > drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops': > >> > drivers/mtd/spi/sf_ops.c:323:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c: In function 'spi_flash_update_block': > >> > common/cmd_sf.c:154:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c:161:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c: In function 'spi_flash_update': > >> > common/cmd_sf.c:218:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c:236:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c: In function 'do_spi_flash_read_write': > >> > common/cmd_sf.c:291:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > common/cmd_sf.c: In function 'do_spi_flash_erase': > >> > common/cmd_sf.c:326:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > common/cmd_nvedit.c: In function 'do_env_export': > >> > common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] > >> > common/cmd_nvedit.c: In function 'do_env_import': > >> > common/cmd_nvedit.c:1036:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > common/cmd_nvedit.c:1036:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] > >> > lib/hashtable.c: In function 'hexport_r': > >> > lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'long unsigned int' [-Wformat] > >> > lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'long unsigned int' [-Wformat] > >> > lib/hashtable.c: In function 'himport_r': > >> > lib/hashtable.c:793:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat] > >> > > >> > > >> > Reverting the following fixes the warnings. > >> > > >> > --- a/arch/m68k/include/asm/posix_types.h > >> > +++ b/arch/m68k/include/asm/posix_types.h > >> > @@ -15,7 +15,7 @@ typedef long __kernel_off_t; > >> > typedef int __kernel_pid_t; > >> > typedef unsigned int __kernel_uid_t; > >> > typedef unsigned int __kernel_gid_t; > >> > -typedef unsigned int __kernel_size_t; > >> > +typedef unsigned long __kernel_size_t; > >> > typedef int __kernel_ssize_t; > >> > typedef long __kernel_ptrdiff_t; > >> > typedef long __kernel_time_t; > >> > > >> > > >> > > >> > In m68k Linux, __kernel_size_t is set to unsigned int. > >> > > >> > So I am not sure if your change is good. > >> > (At least for me, it worsens the situation.) > >> > > >> > Does it depend on each tool-chain ? > >> > > >> > > >> > My tool-chain is like this: > >> > > >> > $ m68k-linux-gcc -v > >> > Using built-in specs. > >> > COLLECT_GCC=m68k-linux-gcc > >> > COLLECT_LTO_WRAPPER=/opt/gcc-4.6.3-nolibc/m68k-linux/bin/../libexec/gcc/m68k-linux/4.6.3/lto-wrapper > >> > Target: m68k-linux > >> > Configured with: /home/tony/buildall/src/gcc/configure --target=m68k-linux --host=x86_64-linux-gnu --build=x86_64-linux-gnu --enable-targets=all --prefix=/opt/cross/gcc-4.6.3-nolibc/m68k-linux/ --enable-languages=c --with-newlib --without-headers --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp --disable-decimal-float --enable-checking=release --with-mpfr=/home/tony/buildall/src/sys-x86_64 --with-gmp=/home/tony/buildall/src/sys-x86_64 --disable-bootstrap --disable-libquadmath > >> > Thread model: single > >> > gcc version 4.6.3 (GCC) > >> > >> That is very unfortunately. I've had m68k warnings forever and I > >> finally got sick of them and built a new toolchain. Mine is: > >> > >> /opt/m68k/bin/m68k-elf-gcc -v > >> Using built-in specs. > >> COLLECT_GCC=/opt/m68k/bin/m68k-elf-gcc > >> COLLECT_LTO_WRAPPER=/opt/m68k/libexec/gcc/m68k-elf/4.6.2/lto-wrapper > >> Target: m68k-elf > >> Configured with: ../configure --target=m68k-elf --prefix=/opt/m68k/ > >> --enable-languages=c --with-newlib --disable-libmudflap > >> --disable-libssp --disable-libgomp --disable-libstdcxx-pch > >> --disable-threads --with-gnu-as --with-gnu-ld --disable-nls > >> --with-headers=yes --disable-checking --without-headers > >> Thread model: single > >> > >> What to do? Is there any way to remove all warnings from m68k without > >> creating others in other toolchain versions? > > > > Ug. I think in general the answer is yes. Only sparc is so old that > > we'd have to start doing pretty ugly things to avoid a warning > > (disk/part.c:453 hwpart might be used uninitalized, but it will always > > be set, based on manual inspection). > > Well at present even with my patch I get link errors, so I haven't > fully solved the problem every for myself. It is just annoying to > always get failures - it would be great if we could resolved these > fully. > > Anyway if my patch makes things worse on other tool chains, then > perhaps we should revert it? Particular if Masahiro has a patch which > corrects the problems (or a toolchain that actually builds). Well, lets cycle back and see if we can get some answers, before we need to start taking some more drastic action perhaps. Jason, is there a toolchain for which MAKEALL -a m68k works? If not, do we need to start removing some no longer used / maintained boards? Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: