Hi All, This is in reference to numpy ticket #1671http://projects.scipy.org/numpy/ticket/1671and the comments on pull request 13 https://github.com/numpy/numpy/pull/13. The original problem was that the gcc compiler was reordering the instructions so that the floating point flags were tested before the computation that needed to be checked. The compiler couldn't know that the flags were being tested in the original code because it didn't know that about PyUFunc_getfperr(), although the fact that floating point computations have side effects should probably have limited any code reordering given that unknown. However, even when the macro using the glibc function fetestexcept was used the problem persisted. This is a known bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186against gcc >= 4.1 that hasn't been addressed in the last four years and it seems unlikely that it will be fixed anytime soon. The upshot is that there is no reliable way to check the floating point flags using either PyUFunc_getfperr or the macro UFUNC_CHECK_STATUS. Enter the ugly workarounds. If a floating point operation produces a value, it is possible to pass a void pointer to that value as a dummy argument to a flag checking routine which will force the value to be computed before the function is called. There are other games that can be played with volatile but I am not convinced that they are robust or portable across compilers. An added complication is that PyUFunc_getfperr is part of the numpy API and the macro UFUNC_CHECK_STATUS is public so if we add workarounds they need new names. There is also the question if we want to expose them. In any case, suggestions as to names and approaches are welcome. And if anyone has a better solution it would be great to hear it. Chuck