[Bug target/59316] gcc.dg/atomic/c11-atomic-exec-5.c FAILs on Solaris/SPARC

[ebotcazou at gcc dot gnu.org]

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?