http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37003
--- Comment #5 from Vas Crabb <vastheman at users dot sourceforge.net>
2011-02-26 09:33:44 UTC ---
I can confirm that this still occurs in gcc version 4.3.3 20090124 (Red Hat
4.3.3-13) and in gcc version 4.5.3 (Ubuntu/Linaro 4.5.2-3ubuntu3).
Using the same input, with the following options on gcc version 4.3.3 20090124
(Red Hat 4.3.3-13) (GCC):
gcc -march=core2 -msse2 -mfpmath=sse -O3 -xc++
This is the prologue of the generated code for the function. The Linux i686
ABI doesn't guarantee any more than 32-bit alignment of %esp on entry to a
function, and there is no code here to force alignment of %esp or %ebp:
_Z18create_geo_to_topoP7DMATRIXdd:
.LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
movl %esp, %ebp
.cfi_offset 5, -8
.cfi_def_cfa_register 5
pushl %ebx
subl $148, %esp
movl 8(%ebp), %ebx
.cfi_offset 3, -12
Later in the function, we find the following code:
leal -56(%ebp), %eax
movapd %xmm0, -88(%ebp)
movsd %xmm5, -40(%ebp)
movl %eax, (%esp)
call _Z11geo_lla_xyzIP7DVECTORS1_EvT_T0_
movapd -88(%ebp), %xmm0
movsd -24(%ebp), %xmm3
It is using movapd to save and restore the contents of %xmm0 around the
function call. Since movapd requires the memory operand to fall on a 16-byte
boundary, this only works if, by chance, the stack was aligned appropriately on
entry to the function. In this case, GCC should probably use some other
instruction (e.g. movupd) to save the contents of the XMM register to avoid the
possibility of causing a general protection fault if the stack isn't aligned as
required.
