search for: _mm_load_ups

That's definitely strange and I've never encountered that. Normally, the only way for _mm_load_ups to generate a segfault is for the input to be invalid memory, in which case the C version should crash too. I suspect the compiler (or something else) may be hiding the real problem. Can you get a debugger and see exactly what assembly statement is causing the crash and what the operands are? Jea...

> I've seen the exact same in my version (mingw on win32), and the problem > was that the stack was misaligned when entering the function, so the temp > registers weren't at 16-byte boundries. That's a possibility. It's easy to check by printing the address of the variables. I know that gcc 3.3 had some alignment issues with _m128 that were supposed to be fixed in

>> I've seen the exact same in my version (mingw on win32), and the problem >> was that the stack was misaligned when entering the function, so the temp >> registers weren't at 16-byte boundries. > > That's a possibility. It's easy to check by printing the address of the > variables. I know that gcc 3.3 had some alignment issues with _m128 that > were

Tom, Thorvald, Could one of you submit the details to the gcc bugzilla so it gets fixed? BTW, is 4.0 affected? Jean-Marc Le vendredi 06 janvier 2006 ? 17:13 -0800, Tom Harper a ?crit : > Thorvald, > > re: > At 03:18 AM 1/6/2006, Thorvald Natvig wrote: > >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... > >And the addresses were not properly

Thorvald, re: At 03:18 AM 1/6/2006, Thorvald Natvig wrote: >I just checked it in the debugger, and this was with gcc 3.4.4 (mingw)... >And the addresses were not properly aligned :( From a bit of googling, >this seems to be a thread problem, as the gcc just maintains 16-byte >alignment of the stack -- if the start function of the thread had >misaligned stack, the misalignment