<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate" href="https://bugs.freedesktop.org/show_bug.cgi?id=79575#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - [radeonsi] Wine's d3d8 test crashes in SITargetLowering::analyzeImmediate" href="https://bugs.freedesktop.org/show_bug.cgi?id=79575">bug 79575</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>Specifically it looks like the wine test actually tries a control word which enables all fpu exceptions. Seems like nvidia drivers had the same problem at some point: <a href="http://bugs.winehq.org/show_bug.cgi?id=28634">http://bugs.winehq.org/show_bug.cgi?id=28634</a> 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). I vaguely remember similar issues in the past in other parts of mesa code. 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 this kind of bug in mesa would be to change the fpu control word on all entry points which could trigger numerical exceptions (and when additionally also consistent results are on the wish list, would need to change it on all entrypoints which could do some fpu calculations)) which I think is not reasonable.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>