On Thu, 5 Dec 2013, Eric Botcazou wrote: > > Note that you could probably just reload the tmp1_var value rather than > > needing to store the fsr value again to clear exceptions from it, unless > > there's an architecture-specific reason the tmp1_var value might no longer > > be the right value to load to clear exceptions. (This is what x86 does > > for SSE state, loading the same value for exceptions-cleared SSE state > > every iteration of the loop.) > > That depends upon the context I'd think: the FSR contains the FP condition > code so reloading tmp1_var will overwrite it with the old value (and SPARC is > not a cc0 target). Would that be safe?
Generically, each iteration of the compare-and-exchange loop should be as if the previous iterations hadn't happened, so restoring all the previous FP state is right in that sense. With regard to the implementation, the insn patterns for the SPARC builtins should specify that the condition code is clobbered when FSR is set, which should avoid any problems in that regard. (The x86 fstenv and fldenv builtins are specified to clobber all the x87 stack registers to ensure that the TOS value saved at fnstenv is valid after fldenv. fldenv is also specified to clobber the condition codes.) > In the meantime, it occurred to me that I very likely don't need to mask the > value of tmp3_var before calling __atomic_feraiseexcept on it. glibc does it > but this looks unnecessary even there. Indeed, __atomic_feraiseexcept is defined to ignore all bits in its argument that aren't exception bits, so no masking is needed. -- Joseph S. Myers jos...@codesourcery.com
