http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59316
--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Mon, 2 Dec 2013, ebotcazou at gcc dot gnu.org wrote: > Ugh. Linux and Solaris disagree on the values of the FE_* macros so we will > need to have OS-dependent code in the sparc_atomic_assign_expand_fenv hook if > we call __atomic_feraiseexcept (I wonder if the same issue exists for > x86/x86-64). 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. > The feupdateenv implementation for SPARC in glibc calls feraiseexcept at the > end (like the x86 implementation), but it does so only for the "old" > exceptions. Yet the manpage seems to indicate that "old" and "new" exceptions > play a symmetrical role: > > The feupdateenv() function installs the floating-point environment rep- > resented by the object *envp, except that currently raised exceptions > are not cleared. After calling this function, the raised exceptions > will be a bitwise OR of those previously set with those in *envp. As > before, the object *envp must be known to be valid. 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. (Some architectures, e.g. x86, may not actually allow for setting exceptions from a saved environment without taking traps for them. IEEE 754-2008 requires operations raiseFlags and restoreFlags that set a particular state of flags without causing traps. If those responsible for the definition of architectures where flags can't actually be set without causing any enabled traps to be taken are concerned about implementability of this aspect of IEEE 754-2008, presumably they'll add new architecture features as needed to implement this. 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.)
