I'm running into a crash that baffled me for awhile. Now I know what's causing it and I'm looking for more information to help me decide on the best course of action. First, a simplified example:
*### blah.F
SUBROUTINE BLAH
CALL STUFF
END
// stuff1.cc
extern "C" {
void blah_();
void stuff_();
}
int main( int argc, char *argv[] ) {
stuff_();
blah_(); // will segfault in stuff_()
return 0;
}
// stuff2.cc
#include <stdio.h>
extern "C" void stuff_() {
char test[127] = {}; // if stack is misaligned, crash occurs here
printf( "0x%08X\n", (unsigned int)&test[0] );
}
#!/bin/bash
# build.sh
# path is already setup for running the compilers
f90 ${1} -ftrap=%none -mt -m32 blah.F -c -o blah.o
clang++ -mcpu=pentium4 -m32 ${2} stuff1.cc stuff2.cc -c
clang++ -mcpu=pentium4 -m32 ${2} stuff1.o stuff2.o blah.o -o stuff
ulimit -c unlimited
rm core.*
./stuff
This is occurring on a fairly new x86 machine using Sun Studio 12.3's fortran compiler and clang 3.4. Ultimately, the array initialization code emitted by clang is crashing when called from Fortran code because it's emitting (SIMD?) instructions that expect the address to be 16-byte aligned, but the Fortran code is defaulting to emitting Pentium 1-compliant executable code and the build of clang I'm using defaults to pentium4. It only happens when the C++ code is built with clang's stack protector, and this may indicate they have a bug in their implementation of stack protector. After I finish this post I may go about running a similar test against gfortran to see if I can reproduce this problem without sun studio.
There also seems to be a lot of contention about whether the SysV i386 ABI is the "right" ABI to use or not, and that may be at the heart of why this is happening.
Anyway, on to the rest of this post. build.sh, as written, takes two positional arguments; ${1} is passed into f90 and ${2} is passed into clang when compiling/linking the C++ code. Additionally, -mcpu=pentium4 appears to be the default for the build of clang I'm using; I only added it to emphasize that it's not targeting generic x86 hardware by default.
# no crash
./build.sh
# crash on all 4
./build.sh "" "-fstack-protector-all -Wstack-protector"
./build.sh "-xtarget=pentium4" "-fstack-protector-all -Wstack-protector"
./build.sh "-xchip=pentium4" "-fstack-protector-all -Wstack-protector"
./build.sh "-xarch=sse2" "-fstack-protector-all -Wstack-protector"
# no crash
./build.sh "-xarch=sse2a" "-fstack-protector-all -Wstack-protector"
./build.sh "-xarch=sse3" "-fstack-protector-all -Wstack-protector"
./build.sh "-O0" "-fstack-protector-all -Wstack-protector"
It looks like the optimizer runs when I select anything above -xarch=sse2, so I'm not absolutely sure that it's not just the optimizer causing the crash to go away as opposed to something being done to make sure the stack is 16-byte aligned for performance reasons. Not using stack protector causes the problem to go away as well, but I'm looking for a solution that allows me to have my cake and eat it too.
Last night when I discovered -xarch=sse3 fixes this, I was ready to just tweak the build and have done with it, then I decided to play around with -xtarget and -xchip and was surprised to discover that the crash still happens, again presumably because the optimizer isn't running.
My suspicion here is that the fortran compiler, when told to use pentium4 with -xtarget and/or -xchip, is not taking into account that sse3 instructions may be used and therefore not aligning the stack.
I'm trying to avoid adding any optimizations to the build, and if I'm right that the optimizer runs when -xarch=sse2a (or higher) are used, then I'm leery of adding that to the build ... but if I don't have another choice, then that may be what I'll have to do.
What would you recommend I do here?
-Brian