Chuck,
It is dying trying to store a our working vector into one of the LLVM
vectors created on the stack. Despite the align-16 directive on the
alloca instruction, it is not always aligning to a 16-byte boundary.
The stack is not necessary 16 bytes aligned on linux/windows. The vector
is really sotred aligned relative to %esp, but %esp value is not good.
This is known problem (PR1636 / PR1649) and I'm currently working on the
solution (actually - stack realignment).
On recent versions of linux (anything in the past 2 years), the stack
will be aligned by gcc, the kernel, and glibc, in all the right
functions.
So unless you misalign it, ...
What is gcc's caller stack alignment assumption on Linux? Unless it's 16 byte or more, the callee will have to dynamically align the stack.
Evan
We force 16 byte alignment in main, and keep it through all gcc
compiled functions.
glibc < 2.4 don't reliably keep stack at 16 bytes through some calls
(qsort, etc), but otherwise, it stays 16 byte aligned.
Hello, Daniel.
glibc < 2.4 don't reliably keep stack at 16 bytes through some calls
(qsort, etc), but otherwise, it stays 16 byte aligned.
Interesting, but why in this case stuff like 'force_align_arg_pointer'
required?
If you mix with older gcc versions (say 2.95), they will default to a
4 byte aligned stack, not a 16 byte one.
You can always ask for > 16 byte stack alignment. 
Evan
I tried to ask for 32 and that didn't seem to help. MallocInst also
seemed to ignore the 16 byte directive. For now, I'm just issuing all
my loads as unaligned and that's working ok.
Thanks,
Chuck.
That's not what I meant. I was replying to Anton that force_align_arg_pointer is still needed even if stack alignment is already 16-byte.
Evan