http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > x86/x86-64 now have their own fenv.c file that defines the FE_* macros > itself and so is immune to that issue. I was hoping that generally the > macros would be defined to correspond to the appropriate bits in the > relevant status register and so the hook could be OS-independent. That's a reasonable assumption and, to answer my own question, Solaris defines the same FE_* macros as Linux on x86. The hitch on the SPARC is that you have 2 sets of flags in the FP status register, the FSR_accrued_exception field and the FSR_current_exception field; Solaris defines the FE_* macros according to the latter and Linux according to the former (so you need a shift to convert between the 2 sets of macros). Hopefully the other OSes use one of these two settings. > They are symmetric as regards which bits are set (would be indicated by > fetestexcept as being set) after feupdateenv. They are not symmetric with > regard to which are raised in the sense of having trap handlers called - > feupdateenv should cause traps (where enabled in the saved environment) > for any exceptions that were set at the time feupdateenv was called, but > not for any that were only set in the saved environment but not in the > environment active when feupdateenv was called. OK, that's what I was more or less suspecting, thanks for confirming. > In any case, c11-atomic-exec-5.c does not test anything relating to enabled > traps, although the feholdexcept code sequence from the target hook is > intended to disable traps and the feupdateenv sequence should then restore > the previous state of which traps were enabled.) The question is: does the UPDATE part of the hook really need to cause traps as the feupdateenv routine, or could it only set the appropriate bits?
