We have numerous cases when GCC (at least 4.9.2) implicitly generates SSE/SSE2 instructions (e.g. when using -O3 -march=pentium4) but doesn't align arguments for them on the 16-byte boundary as required by the x86 specification. In case of stack-based memory this can be forced globally with -mstackrealign but it's a clear abuse of this option and it also doesn't help when arguments are from the dynamic memory or from global data segments. Such memory may only be aligned on per-variable basis using special GCC variable attribute to force fixed alignment but this is usually not an acceptable solution either. Such an alignment should be done automatically whenever GCC generates SSE/SSE2 and not doing so looks like a bug in our port (as on other platforms it works w/o any additional hassle).
A good test case is FIrefox. See bitwiseworks/mozilla-os2#266 (comment) and below. But perhaps a simple test case for testing purposes should be written when working on this problem.
We have numerous cases when GCC (at least 4.9.2) implicitly generates SSE/SSE2 instructions (e.g. when using
-O3 -march=pentium4) but doesn't align arguments for them on the 16-byte boundary as required by the x86 specification. In case of stack-based memory this can be forced globally with-mstackrealignbut it's a clear abuse of this option and it also doesn't help when arguments are from the dynamic memory or from global data segments. Such memory may only be aligned on per-variable basis using special GCC variable attribute to force fixed alignment but this is usually not an acceptable solution either. Such an alignment should be done automatically whenever GCC generates SSE/SSE2 and not doing so looks like a bug in our port (as on other platforms it works w/o any additional hassle).A good test case is FIrefox. See bitwiseworks/mozilla-os2#266 (comment) and below. But perhaps a simple test case for testing purposes should be written when working on this problem.