I belive that i found an issue in gcc 4.7.2 this afternoon I was compile the google angleproject - a gles2 implementation on d3d9. this project require SSE2 support to compiled, so I enable it with "-march=nocona -O3" to get this work done, finally I got the Dlls. but when I try to run a test program compiled by VC++ that use the Dlls compiled by gcc, it always crashed by "Access Violation". after some analyses, I located the crashed point is a function at "src\libGLESv2\ProgramBinary.cpp" line 2681 named "bool ProgramBinary::validateSamplers(InfoLog *infoLog)" there are some statement in it: bool ProgramBinary::validateSamplers(InfoLog *infoLog) { // if any two active samplers in a program are of different types, but refer to the same // texture image unit, and this is the current program, then ValidateProgram will fail, and // DrawArrays and DrawElements will issue the INVALID_OPERATION error. const unsigned int maxCombinedTextureImageUnits = getContext()->getMaximumCombinedTextureImageUnits(); TextureType textureUnitType[MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF]; //TextureType is an enum //MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF==20 //comment by jjwang for (unsigned int i = 0; i < MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF; ++i) { textureUnitType[i] = TEXTURE_UNKNOWN; } ... } gcc generate six sse2 "movdqa" instructions to unrolling the loop, great works! but the textureUnitType is not aligned by 32 bytes, so It crashed! movdqa xmm0,xmmword ptr ds:[67B4A7D0h] movdqa xmmword ptr [esp+10h],xmm0;<=====crashed here movdqa xmmword ptr [esp+20h],xmm0 movdqa xmmword ptr [esp+30h],xmm0 movdqa xmmword ptr [esp+40h],xmm0 movdqa xmmword ptr [esp+50h],xmm0 then I made some changes and it works perfectly! __attribute__((aligned(32))) TextureType textureUnitType[MAX_COMBINED_TEXTURE_IMAGE_UNITS_VTF]; the implicit issue like this are very hard to understand for someone never know sse2 and just want to use the Dlls project. I belive that align the "local variable" that used by implicit sse instructions is compiler's work not human's, so think about it please! sorry my poor english, thanks! 03-11-2003 jjwang
If the failure is on reading from the stack pointer, then it must be that some caller misaligns the stack. You have mentioned what target you're using, so it is hard to guess what is faulty. E.g. on i?86-linux stack must be 16-byte aligned, if it isn't, you're violating the ABI (but gcc has some options where you can ask it to realign the stack dynamically, or assume smaller alignment etc.).
"but when I try to run a test program compiled by VC++ that use the Dlls compiled by gcc" so I assume this is on mingw32/64. Which means that whatever ABI is in effect is either violated by VC++ or by GCC. CCing win target maintainers. Please resolve whether this is a GCC or a VC++ bug.
(In reply to comment #2) > "but when I try to run a test program compiled by VC++ that use the Dlls > compiled by gcc" > > so I assume this is on mingw32/64. Which means that whatever ABI is > in effect is either violated by VC++ or by GCC. > > CCing win target maintainers. Please resolve whether this is a GCC or > a VC++ bug. This problem are very clear, mingw/gcc 4.7.2 generate implicit SSE2 instructions that require alignment and gcc just leave everything as it is, then VC++ does not aligns the program's stack and call to the DLLs(shared library in windows) produced by GCC, finally the program crashed! In my view I think even VC++ does not aligns the stack, the function exported by a DLL that compiled by GCC should self-aligned not just leave things as it is, Specifically when GCC decide to use the vector instructions that require alignment(just like SSE2), and users never realized it! I think the bottom line is "program can't just crashed!" ps: follow Jakub Jelinek's says I add "-mstackrealign" option, the issue is gone, so Strictly speaking it can't be a bug, just a Potential issue. regards 03-12-2013 jjwang
I think one rule can be add to gcc that is: if GCC decide to use the vector instructions that require alignment in condition the users are not realized it, the variable should be aligned automaticly that referenced by the instructions jj
Issue here is that x64 ABI just requires that stack has 16-byte alignment. So that means within a function, using instruction requestion higher-alignment, compiler should either make sure that for those instructions variables get desired alignment, or that unaligned access is used. Otherwise I don't see here a way to resolve that, especially in scenario that code gets used by foreign compiler.