Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1330 gcc 4.4 generates unaligned stack offsets with sse2 code

closed-invalid
nobody
gcc (462)
2009-08-09
2009-08-08
Peter Hurley
No

gcc 4.4 is generating stack frame offsets to compiler-generated locals that are not 16-byte aligned for sse2 instructions, causing #GP(0) faults.

This bug is different than artifact id# 1008330 (movaps problem with mingw). That bug was due to the fact that the base pointer itself was not aligned at function entry, rather than frame offsets being unaligned.

In the attached submission file, compiled with:
g++ -O3 -msse3 -g3 -Wall -c -save-temps -osubmission.o submission.cpp
the following assembly code is emitted:
/APP
# 60 "..\submission.cpp" 1
movddup 16(%eax),%xmm0
# 0 "" 2
/NO_APP
LBE42:
LBE41:
.loc 1 103 0
addpd %xmm0, %xmm0
movapd %xmm0, -88(%ebp)

The frame offset of the destination operand in the movapd instruction, -88, is not 16-byte aligned and causes a GP fault.

The same file compiled with:
g++ -O0 -msse3 -g3 -Wall -c -save-temps -osubmission.o submission.cpp
generates a different sequence for the same source (obviously) that does not exhibit the same error as above. However, later in the same output the following sequence is emitted:
.loc 1 127 0
movsd -40(%ebp), %xmm0
movhpd -32(%ebp), %xmm0
cmpltpd -216(%ebp), %xmm0
movlpd %xmm0, -40(%ebp)
movhpd %xmm0, -32(%ebp)

The frame offset value of the source operand in the cmpltpd instruction, -216, is not 16-byte aligned, and generates a GP fault.

Discussion

  • Peter Hurley
    Peter Hurley
    2009-08-08

    Submission source file exhibiting described behavior

     
    Attachments
  • Peter Hurley
    Peter Hurley
    2009-08-08

    Forgot to include environment
    -- Enviroment --
    intel harpertown
    windows xp pro sp3
    gcc v.4.4.0 (mingw32 target)
    binutils v.2.19.1

     
  • Peter Hurley
    Peter Hurley
    2009-08-09

    I closed this submission because this problem is related to artifact id# 1008330.

    I did not realize that the implicit ABI change was that ebp *must* be offset by 8 from 16-byte boundaries, ie. that -8(%ebp) *does* refer to a 16-byte aligned address.

     
  • Peter Hurley
    Peter Hurley
    2009-08-09

    • status: open --> closed-invalid