https://bugs.freedesktop.org/show_bug.cgi?id=79575
--- Comment #8 from Henri Verbeet hverbeet@gmail.com --- (In reply to comment #7)
Looks like this is happening purely for testing if a fpu control word would be preserved, the actual value used by d3d does disable them just fine (though, of course, this could also happen on any app, not just wine, if it unmasks exceptions before calling into mesa code).
It's perhaps important to point out that Wine isn't a single application as such, and we don't have a lot of control over how individual applications setup the FPU. The test in question exists because some applications expect us to setup the FPU in a specific way, while others expect us to leave it alone. Without having looked much into the llvm source for the backtrace, it's perhaps also a bit odd that compiling a pass-through shader is doing anything involving denormals in the first place.
Though IIRC you aren't actually expected to leave the fpu control word in a non-standard state when you're calling into library code, so I'm not really sure if this qualifies as a mesa bug. In any way since this happens in llvm code finally here it might even be a bug there. I guess the only way to fix
Mostly just for reference, regressions every now and then aside, the Wine D3D tests pretty much just pass with r600g / sb; that's currently my main development setup. (And somewhat off-topic, but not entirely unrelated to this bug, the reason that that's not a radeonsi system is because I think the llvm dependency is just painful to work with.)