Re: [patch 2.6.19-rc6] Stop gcc 4.1.0 optimizing wait_hpet_tick away

[Willy Tarreau]

On Wed, Nov 29, 2006 at 04:08:00AM -0500, Jakub Jelinek wrote:
> On Wed, Nov 29, 2006 at 02:56:20PM +1100, Keith Owens wrote:
> > Nicholas Miell (on Tue, 28 Nov 2006 19:08:25 -0800) wrote:
> > >On Wed, 2006-11-29 at 13:22 +1100, Keith Owens wrote:
> > >> Compiling 2.6.19-rc6 with gcc version 4.1.0 (SUSE Linux),
> > >> wait_hpet_tick is optimized away to a never ending loop and the kernel
> > >> hangs on boot in timer setup.
> > >> 
> > >> 0000001a <wait_hpet_tick>:
> > >>   1a:   55                      push   %ebp
> > >>   1b:   89 e5                   mov    %esp,%ebp
> > >>   1d:   eb fe                   jmp    1d <wait_hpet_tick+0x3>
> > >> 
> > >> This is not a problem with gcc 3.3.5.  Adding barrier() calls to
> > >> wait_hpet_tick does not help, making the variables volatile does.
> > >> 
> > >> Signed-off-by: Keith Owens <kaos@xxxxxxxxxx>
> > >> 
> > >> ---
> > >>  arch/i386/kernel/time_hpet.c |    2 +-
> > >>  1 file changed, 1 insertion(+), 1 deletion(-)
> > >> 
> > >> Index: linux-2.6/arch/i386/kernel/time_hpet.c
> > >> ===================================================================
> > >> --- linux-2.6.orig/arch/i386/kernel/time_hpet.c
> > >> +++ linux-2.6/arch/i386/kernel/time_hpet.c
> > >> @@ -51,7 +51,7 @@ static void hpet_writel(unsigned long d,
> > >>   */
> > >>  static void __devinit wait_hpet_tick(void)
> > >>  {
> > >> -	unsigned int start_cmp_val, end_cmp_val;
> > >> +	unsigned volatile int start_cmp_val, end_cmp_val;
> > >>  
> > >>  	start_cmp_val = hpet_readl(HPET_T0_CMP);
> > >>  	do {
> > >
> > >When you examine the inlined functions involved, this looks an awful lot
> > >like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
> > >
> > >Perhaps SUSE should fix their gcc instead of working around compiler
> > >problems in the kernel?
> > 
> > Firstly, the fix for 22278 is included in gcc 4.1.0.
> 
> This actually sounds more like http://gcc.gnu.org/PR27236
> And that one is broken in 4.1.0, fixed in 4.1.1.

Then why not simply check for gcc 4.1.0 in compiler.h and refuse to build
with 4.1.0 if it's known to produce bad code ? I find it a bit annoying
that we start fixing every place affected by buggy compiler versions,
especially when the fix is already available.

> 	Jakub

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/