linux-mips
[Top] [All Lists]

Re: GCC-4.3.3 sillyness

To: Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: GCC-4.3.3 sillyness
From: Manuel Lauss <mano@roarinelk.homelinux.net>
Date: Fri, 30 Jan 2009 09:55:28 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <Pine.LNX.4.64.0901300921380.17617@anakin>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20090130074407.GA12368@roarinelk.homelinux.net> <Pine.LNX.4.64.0901300921380.17617@anakin>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.16 (2007-06-09)
Hi Geert,

On Fri, Jan 30, 2009 at 09:23:38AM +0100, Geert Uytterhoeven wrote:
> On Fri, 30 Jan 2009, Manuel Lauss wrote:
> >   CC      arch/mips/kernel/traps.o
> > cc1: warnings being treated as errors
> > /linux-2.6.git/arch/mips/kernel/traps.c: In function 'set_uncached_handler':
> > /linux-2.6.git/arch/mips/kernel/traps.c:1599: error: format not a string 
> > literal and no format arguments
> > 
> > The fastest fix is the patch below, but I don't know whether it is
> > the right thing to do.
> > 
> > ---
> > 
> > diff --git a/arch/mips/Makefile b/arch/mips/Makefile
> > index 7378b91..70ddf83 100644
> > --- a/arch/mips/Makefile
> > +++ b/arch/mips/Makefile
> > @@ -78,7 +78,7 @@ all-$(CONFIG_BOOT_ELF64)  := $(vmlinux-64)
> >  # machines may also.  Since BFD is incredibly buggy with respect to
> >  # crossformat linking we rely on the elf2ecoff tool for format conversion.
> >  #
> > -cflags-y                   += -G 0 -mno-abicalls -fno-pic -pipe
> > +cflags-y                   += -G 0 -mno-abicalls -fno-pic -pipe -Wno-format
> >  cflags-y                   += -msoft-float
> >  LDFLAGS_vmlinux                    += -G 0 -static -n -nostdlib
> >  MODFLAGS                   += -mlong-calls
> 
> No, you don't want to disable printf()-style format checking.
> 
> diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c
> index f6083c6..16f499c 100644
> --- a/arch/mips/kernel/traps.c
> +++ b/arch/mips/kernel/traps.c
> @@ -1596,7 +1596,7 @@ void __cpuinit set_uncached_handler(unsigned long 
> offset, void *addr,
>               ebase += (read_c0_ebase() & 0x3ffff000);
>  
>       if (!addr)
> -             panic(panic_null_cerr);
> +             panic("%s", panic_null_cerr);
>  
>       memcpy((void *)(uncached_ebase + offset), addr, size);
>  }
> 
> Hwoever, I'm a bit surprised gcc isn't smart enough to notice the string is
> fixed and safe. Perhaps because panic_null_cerr is not const?

There's a similar one in cpu-probe.c which doesn't bother it at all,
probably because the call to panic() has 2 arguments instead of one.
I say it's a gcc bug ;-)

Thanks!
        Manuel Lauss

<Prev in Thread] Current Thread [Next in Thread>