<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Richard and I have been hammering at our build system and code to try to solve several crashes on OS X with Xcode 7.3. Several of them came from the fact that we trap NaN whereas Xcode 7.3 aggressive optimisations produce code that may create a NaN but still deliver the correct final result. A trivial example came from cctbx/xray/conversions.h. We have<div class=""><br class=""></div><div class=""><font face="Menlo" class="">if (f_sq > 0) f = std::sqrt(f_sq);</font></div><div class=""><font face="Menlo" class="">else f = 0;</font></div><div class=""><br class=""></div><div class="">With the version of clang shipping with Xcode 7.3, both branches are evaluated in parallel before selecting the result based on the test f_sq > 0. This is done so as not to stall the pipeline and this can result in much faster code indeed. But that means that every time f_sq < 0, a NaN will be produced, and in the context of our tests, this means we crash.</div><div class=""><br class=""></div><div class="">Richard and I avoided the elephant in the room, stop to trap NaN, and as a result came with uglier and uglier fixes. Moreover, we are now at the mercy of the compiler applying such an optimisation to another file at the next update of Xcode, which would then force us to fix the compilation of said file in the relevant SConscript. It’s a loosing game.</div><div class=""><br class=""></div><div class="">Thus I reckon that at least on OS X, we should stop trapping NaN.</div><div class=""><br class=""></div><div class="">That will leave us with the true clang regression for which I will try to submit reduced cases to the clang bugzilla.</div><div class=""><br class=""></div><div class="">Best wishes,</div><div class=""><br class=""></div><div class="">Luc</div><div class=""><br class=""></div></body></html>