The following reply was made to PR port-i386/21255; it has been noted by GNATS.

From: Jim Bernard <jbernard@mines.edu>
To: mrg@netbsd.org
Cc: gnats-bugs@netbsd.org, thorpej@netbsd.org,
	gnats-admin@netbsd.org, sverre@viewmark.com
Subject: Re: PR/21255 CVS commit: src/gnu/dist/gcc4
Date: Sat, 20 May 2006 16:58:36 -0600

 On Thu, Apr 20, 2006 at 10:25:56AM +0000, matthew green wrote:
 > The following reply was made to PR port-i386/21255; it has been noted by GNATS.
 > 
 > From: matthew green <mrg@netbsd.org>
 > To: gnats-bugs@netbsd.org
 > Cc: 
 > Subject: PR/21255 CVS commit: src/gnu/dist/gcc4
 > Date: Thu, 20 Apr 2006 10:20:40 +0000 (UTC)
 > 
 >  Module Name:	src
 >  Committed By:	mrg
 >  Date:		Thu Apr 20 10:19:48 UTC 2006
 >  
 >  Update of /cvsroot/src/gnu/dist/gcc4
 >  In directory ivanova.netbsd.org:/tmp/cvs-serv12371
 >  
 >  Log Message:
 >  initial import of GCC 4.1 branch, from 2006-04-20.  list of changes way
 >  too large to list, but see:
 >  	http://gcc.gnu.org/gcc-3.4/changes.html
 >  	http://gcc.gnu.org/gcc-4.0/changes.html
 >  	http://gcc.gnu.org/gcc-4.1/changes.html
 >  for the details.
 >  
 >  Status:
 >  
 >  Vendor Tag:	FSF
 >  Release Tags:	gcc-4-1-20060420
 
   Well, I finally found a bit of time to try out gcc 4.1.1---built a 3.99.20
 system from sources updated May 18, 2006 and _without_ the patch to crt0.c,
 which I have been using happily ever since the spring of 2003.  And it appears
 that the 8-byte stack-alignment problem has been fixed.  Here's a slightly
 modified version of the test code:
 
 #include <stdio.h>
 #define N 10000
 int main (int argc, char **argv) {
 double *x;
 int i, j;
 
 /*
 x=(double*)malloc((N+1)*sizeof(double));
  */
 double y[N+1];
 x = y;
 if(argc==2) x=(double*)((int)x+4);
 
 printf("0x%x\n", (int)x);
 printf("%d\n", (int)x%8);
 printf("%d\n", (int)x%16);
 for(i=0;i<N;i++) x[i]=(double)i;
 for(i=0;i<N;i++) for (j=0;j<N;j++) x[i]=0.5*(x[j]+x[i]);
 
 printf("%f\n", x[N-1]);
 exit(0);
 }
 
  If you compile it (e.g., gcc -O3) and link it to 4 different names:
 
    ln a.out l
    ln a.out ll
    ln a.out lll
    ln a.out llll
 
 you'll find that execution times are all essentially the same, and the
 address of the double-precision array x changes.  Curiously, it changes
 by 16 bytes, always remaining on an odd 8-byte boundary.  Also, if the
 array is allocated with malloc, instead of being declared, the alignment
 is (still) optimal.
 
   I haven't been able to test with fortran code, since the fortran compiler
 seems to have disappeared, to my considerable disappointment.  Once I figure
 out how to get it back, I'll do some more testing with fortran code, but at
 this point it looks like this alignment problem is solved.
 
   Thanks!
 
   BTW: Just for the record, here's the latest version of the patch I was
 using for crt0.o.  The only difference from the one previously in the PR is
 the conditional inclusion of the 4-byte extra offset of the stack pointer
 when GCC < 3 is used.
 
 --- crt0.c-dist	2001-12-31 04:04:20.000000000 -0700
 +++ crt0.c	2003-04-26 17:45:54.000000000 -0600
 @@ -44,19 +44,24 @@
  "	.align	4			\n"
  "	.globl	__start			\n"
  "	.globl	_start			\n"
  "_start:				\n"
  "__start:				\n"
 +"	movl	%esp,%eax		# save stack pointer		\n"
 +"	and	$0xfffffff8,%esp	# align to 8-byte boundary	\n"
 +#if defined(__GNUC__) && (__GNUC__ < 3)
 +"	subl	$4,%esp			# compensate for later offset	\n"
 +#endif
  "	pushl	%ebx			# ps_strings	\n"
  "	pushl	%ecx			# obj		\n"
  "	pushl	%edx			# cleanup	\n"
 -"	movl	12(%esp),%eax		\n"
 -"	leal	20(%esp,%eax,4),%ecx	\n"
 -"	leal	16(%esp),%edx		\n"
 -"	pushl	%ecx			\n"
 +"	movl	(%eax),%ebx		# argc		\n"
 +"	leal	4(%eax),%ecx		# *argv		\n"
 +"	leal	8(%eax,%ebx,4),%edx	# *envp		\n"
  "	pushl	%edx			\n"
 -"	pushl	%eax			\n"
 +"	pushl	%ecx			\n"
 +"	pushl	%ebx			\n"
  "	call	___start");
  
  void
  ___start(argc, argv, envp, cleanup, obj, ps_strings)
  	int argc;
 
 --Jim