Resamplers Crash When SSE Enabled (MinGW)

[NewCreature]

When playing a module with my application that uses DUMB, my application kept crashing when trying to render the audio. I tracked the crash down into resampler_run_cubic_sse() in 'src/helpers/resampler.c'. Specifically, it crashes when calling _mm_setzero_ps().

I was able to work around the issue by setting USE_SSE to OFF when configuring the build options for DUMB.

I found this page which may be useful in solving the issue. My application spawns a thread to run the audio rendering code. I also tried using Allegro 5 and it has the same crash. Allegro 5's audio codec streamers use a separate thread as well.

I went ahead and built a single-threaded test application and it doesn't crash on the same code.

[kode54]

That opcode can’t crash unless something is seriously broken with your operating system. All it does is load an SSE register with zero. Unless you’re mixing MMX code in there with floating point x87 code and mixing states.

[kode54]

Try fixing up the thread entry like they say there? I don’t actually use gcc on Windows, so I haven’t verified whether there are stack alignment assumptions that are totally the compiler’s fault. I suppose that source file needs evil stack realignment crap applied to it just for gcc users.

[NewCreature]

I wonder if this is fixed with newer versions of GCC. I wasn't able to get it working with -mstackrealign.

[Rondom]

Blind guess: Have you tried making sure that all parts of you application (allegro, dumb and the application itsefl) are compiled with -mstackrealign (and maybe -msse)?

Regarding versions, MSYS2 ships with a MinGW-w64-GCC 7.2.

[NewCreature]

I recompiled everything with -mstackrealign and -msse and it still crashes on the SSE call. I'll try MSYS2 soon.

[kode54]

Please make sure that your compiler is emitting the xorps opcode, and that your CPU supports SSE. That’s at least a Pentium 3 or an Athlon XP, correct?

[NewCreature]

I've finally migrated my Windows development environment over to MinGW-w64 and the issue is not present with GCC 7.4.

Maybe since MinGW32 is still the top result when searching for MinGW, there should be a note about the issue somewhere so users will know to use MinGW-w64 or disable SSE if the want to use MinGW32.