GCC 4.2.1 produces broken 2.6.22.1 kernel.

GCC 4.2.1 produces broken 2.6.22.1 kernel.

[Andrew Walrond]

Andrew Walrond wrote:
> 
> I've got a horrible feeling I've just spent a day fighting against a
> miscompilation by gcc-4.2.
> 
> Perhaps this is a known problem? I'm rebuilding with gcc-4.1.2 now and
> will report back shortly....
> 

Confirmed; GCC 4.2.1 (vanilla) produces a broken 2.6.22.1 kernel. I
don't know why, or whether GCC or the kernel is at fault, but the exact
same kernel and config builds and boots fine with GCC 4.1.2.

This is on a Sun T1000 niagra box. Anything I can do? let me know.

Andrew Walrond

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

From: Andrew Walrond <andrew@walrond.org>
Date: Mon, 06 Aug 2007 18:53:14 +0100

> Confirmed; GCC 4.2.1 (vanilla) produces a broken 2.6.22.1 kernel. I
> don't know why, or whether GCC or the kernel is at fault, but the exact
> same kernel and config builds and boots fine with GCC 4.1.2.

Thanks for tracking this down, if I get some time I'll
reproduce it here and try to figure out if it could
be a kernel side issue of some sort.

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

From: Andrew Walrond <andrew@walrond.org>
Date: Mon, 06 Aug 2007 18:53:14 +0100

> Confirmed; GCC 4.2.1 (vanilla) produces a broken 2.6.22.1 kernel. I
> don't know why, or whether GCC or the kernel is at fault, but the exact
> same kernel and config builds and boots fine with GCC 4.1.2.
> 
> This is on a Sun T1000 niagra box. Anything I can do? let me know.

Just an update that I did look into this and I do know what is being
miscompiled and how.

I'll try to follow through on this and come up with a testcase
for the gcc folks to look into.  But it may need to wait until
after Kernel Summit and the Netfilter Workshop.

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[Andrew Walrond]

David Miller wrote:
> 
> Just an update that I did look into this and I do know what is being
> miscompiled and how.
> 
> I'll try to follow through on this and come up with a testcase
> for the gcc folks to look into.  But it may need to wait until
> after Kernel Summit and the Netfilter Workshop.
> 

Thanks for the update; I've reverted to 4.1.* for kernel compiles in the
meantime.

BTW, I have been configuring for SLUB and I noticed your message on LKML
about it. Should I revert to SLAB? (I'm running 2.6.22.x on 2Gb T1000's)

Andrew Walrond

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

From: Andrew Walrond <andrew@walrond.org>
Date: Sat, 25 Aug 2007 09:05:11 +0100

> David Miller wrote:
> > 
> > Just an update that I did look into this and I do know what is being
> > miscompiled and how.
> > 
> > I'll try to follow through on this and come up with a testcase
> > for the gcc folks to look into.  But it may need to wait until
> > after Kernel Summit and the Netfilter Workshop.
> > 
> 
> Thanks for the update; I've reverted to 4.1.* for kernel compiles in the
> meantime.
> 
> BTW, I have been configuring for SLUB and I noticed your message on LKML
> about it. Should I revert to SLAB? (I'm running 2.6.22.x on 2Gb T1000's)

Both should work fine, I happen to be using SLUB lately.

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

Better late than never...

Ok, I think I nailed this, the simplest test case is:

register unsigned long regval asm("g5");

extern void cond_resched(void);

unsigned int var;

void *expression(unsigned long regval)
{
  void *ret;

  __asm__("" : "=r" (ret) : "0" (&var));
  return ret + regval;
}

void func(void **pp)
{
  int i;

  for (i = 0; i < 56; i++) {
    cond_resched();
    *pp = expression(regval);
  }
}

If you build that with "gcc-4.2 -m64 -Os -S -o test.s test.c"
the compiler moves expression() outside of the loop because it
things it is invariant.

The dataflow pass doesn't mark global registers correctly, and
the new thing in gcc-4.2.x vs. gcc-4.1.x is that it uses the
dataflow pass for the loop optimizers.

I've bootstrapped and regression tested the following gcc-4.2.x
patch, I'll test some test kernel builds after I get some sleep.

--- ./gcc/df-scan.c.ORIG	2007-10-16 02:07:46.000000000 -0700
+++ ./gcc/df-scan.c	2007-10-16 23:00:32.000000000 -0700
@@ -1584,12 +1584,19 @@ df_insn_refs_record (struct dataflow *df
 		 so they are recorded as used.  */
 	      for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
 		if (global_regs[i])
-		  df_uses_record (dflow, &regno_reg_rtx[i],
-				  DF_REF_REG_USE, bb, insn, 
-				  0);
+		  {
+		    df_uses_record (dflow, &regno_reg_rtx[i],
+				    DF_REF_REG_USE, bb, insn, 0);
+		    df_ref_record (dflow, regno_reg_rtx[i], &regno_reg_rtx[i],
+				   bb, insn, DF_REF_REG_DEF, 0, true);
+		  }
+
 	      EXECUTE_IF_SET_IN_BITMAP (df_invalidated_by_call, 0, ui, bi)
-	        df_ref_record (dflow, regno_reg_rtx[ui], &regno_reg_rtx[ui], bb, 
-			       insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER, false);
+		{
+		  if (!global_regs[ui])
+		    df_ref_record (dflow, regno_reg_rtx[ui], &regno_reg_rtx[ui], bb, 
+				   insn, DF_REF_REG_DEF, DF_REF_MAY_CLOBBER, false);
+		}
 	    }
 	}
 

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[Andrew Walrond]

David Miller wrote:
> 
> The dataflow pass doesn't mark global registers correctly, and
> the new thing in gcc-4.2.x vs. gcc-4.1.x is that it uses the
> dataflow pass for the loop optimizers.
> 

I look forward to testing this when you think it's ready. As well as the
kernel, I discovered several other packages which behave oddly and/or
crash when compiled 64bit with 4.2, but seem just fine with 4.1. (My
custom server distro is pure 64bit for simplicity sake (only 1 version
of libs etc etc), so I'm probably the only one to have noticed).

Andrew Walrond

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

From: Andrew Walrond <andrew@walrond.org>
Date: Wed, 17 Oct 2007 13:14:32 +0100

> David Miller wrote:
> > 
> > The dataflow pass doesn't mark global registers correctly, and
> > the new thing in gcc-4.2.x vs. gcc-4.1.x is that it uses the
> > dataflow pass for the loop optimizers.
> > 
> 
> I look forward to testing this when you think it's ready.

I just have done some SMP kernel testing on my Niagara-2 systems
and it looks really good with that gcc-4.2.x patch I posted.

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[Andrew Walrond]

David Miller wrote:
> 
> I just have done some SMP kernel testing on my Niagara-2 systems
> and it looks really good with that gcc-4.2.x patch I posted.
> -

Excellent. I'll give it a whirl here aswell.

Will you be posting the patch to the gcc ML? My little distro is
wonderfully symmetric across x86/x86_64/itanium2/sparc64 except for the
need to use gcc 4.1 on sparc64, so it will be a nice to get a fix merged
for 4.2.3 and 4.3/mainline.

And how are those Niagara2 systems shaping up? Much improvement over
Niagara1 ?

Andrew Walrond

Re: GCC 4.2.1 produces broken 2.6.22.1 kernel.

[David Miller]

From: Andrew Walrond <andrew@walrond.org>
Date: Thu, 18 Oct 2007 10:52:43 +0100

> Will you be posting the patch to the gcc ML? My little distro is
> wonderfully symmetric across x86/x86_64/itanium2/sparc64 except for the
> need to use gcc 4.1 on sparc64, so it will be a nice to get a fix merged
> for 4.2.3 and 4.3/mainline.

I already did.  I'm testing the patch against mainline too so
I can check it into the SVN repository first, then ask for
gcc-4.2.x stable branch approval.

> And how are those Niagara2 systems shaping up? Much improvement over
> Niagara1 ?

I have early access systems so I can't really say much, sorry.