Use of SSE vectors on linux requires stack realignment

[llvmbot]

Bugzilla Link	951
Resolution	FIXED
Resolved on	Apr 23, 2008 15:58
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#1438
Reporter	LLVM Bugzilla Contributor
CC	@asl,@nlewycky

Extended Description

Two of the SSE tests fail on Linux with a SEGV. The output is this:

/proj/llvm/llvm/projects/llvm-test/RunSafely.sh 500 /dev/null
Output/sse.stepfft.out-llc Output/sse.stepfft.llc
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
Core was generated by `Output/sse.stepfft.llc'.
Program terminated with signal 11, Segmentation fault.

warning: svr4_current_sos: Can't read pathname for load map: Input/output error

(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
#​0 0x0804871e in .BB1_13 ()
#​0 0x0804871e in .BB1_13 ()
#​1 0x00000000 in ?? ()

Nearly identical results (the stack dump is different) occur for JIT. The JIT
test also produces this:
Previous frame inner to this frame (corrupt stack?)

Possibly the stack is getting corrupted?

[lattner]

IIRC, the stack is only 4-byte aligned on linux, not 16-byte aligned. Some majik may need to be done in
the code generator to support this.

[llvmbot]

I'm seeing this with sse.stepfft.native on FreeBSD 6.2-RELEASE with gcc 4.0.4
from ports, but not with the base system compiler (gcc 3.4.6)

The following (somewhat nasty) patch fixes the native binary produced by gcc
4.0.4 in my case:

--- sse.stepfft.c.old Tue May 22 17:26:59 2007
+++ sse.stepfft.c Tue May 22 17:31:20 2007
@@ -156,7 +156,9 @@
float a[][2],b[][2],c[][2],d[][2],w[][2],sign;
{
int j,k,jc,jw,l,lj,mj2,mseg;

• float rp,up,wr[4],wu[4];

• float rp,up,

•  wr[4] __attribute__ ((aligned(16))),
  

•  wu[4] __attribute__ ((aligned(16)));
  

  __m128 xmm0,xmm1,xmm2,xmm3,xmm4,xmm5,xmm6,xmm7;

  mj2 = 2*mj;

[lattner]

Anton, isn't this bug invalid?

[asl]

Seems, it's not invalid. The testcases are still failing for me randomly (e.g. depending on optimization level, etc).

[asl]

*** Bug llvm/llvm-bugzilla-archive#1438 has been marked as a duplicate of this bug. ***

[lattner]

Is this because of an llvm bug or a bug in the testcase? The patch in comment 2 suggests that the code is not written correctly. Programs shouldn't assume an array of floats has 16-byte alignment. If they are, they should be corrected.

[asl]

Well, I don't exactly know right now. The patch seems to be already in.

[lattner]

Anton, is this fixed?

[asl]

Not yet. In progress.

[asl]

This is really fixed now :)