Re: gcc/libm floating-point bug?

On Tue, 2003-05-27 at 11:10, Bruce Evans wrote:
> On Tue, 27 May 2003, Doug Rabson wrote:
> 
> > On Thursday 22 May 2003 6:32 pm, David O'Brien wrote:
> > > On Thu, May 22, 2003 at 09:36:23AM -0500, Anti wrote:
> > > > p4 should expand to "-march=pentium4 -mno-sse2"
> > >
> > > If we are going to make any change, it should be one we know will
> > > deal with the issue once and for all.  I also considered submitting a
> > > patch like that, but it is too late in the game to figure out if
> > > "-march=pentium4 -mno-sse2" would be sufficient in all cases.
> >
> > Even for special cases, it is hard to use -msse (or -msse2) with
> > gcc-3.2.x since it doesn't always manage to 16-byte align the stack
> > pointer. This makes it hard to declare local vector float variables
> > safely. All of this appears to be fixed in gcc-3.3-prerelease at least.
> 
> Isn't this "fixed" in gcc-3.any (gcc-3.2 on i386's at least) except
> for signal stacks which are partly the kernel's responsibility?  gcc-3.2
> still pessimizes stack alignment and invites bugs by doing it in
> functions that don't need it and depending on callers doing it.

When I was experimenting with this recently using our current compiler
(gcc-3.2.2-ish?) it was quite broken. It carefully managed the stack
pointer in main so that it was aligned at the point of calling my test
function. This meant that pushing the return address broke the alignment
and since the callee expected a 16-byte aligned stack, it faulted the
first time it tried to use 'movaps' (16-byte vector float move) on a
stack variable.

The intel compiler inserts code into the function profile which enforces
alignment where necessary. This might be the better approach when not
all functions need the alignment.