Re: [musl] Considering x86-64 fenv.s to C

[Szabolcs Nagy <nsz@port70.net>]

* Damian McGuckin <damianm@esi.com.au> [2020-01-19 20:07:56 +1100]:
> On Fri, 17 Jan 2020, Rich Felker wrote:
> 
> > > x86_64
> > > 
> > > *	In assembler
> > > 
> > > *	Why does 'feclearexcept' disrespect the flags by clearing ALL x86 bits?
> > 
> > As you said above, updating x87 status register is expensive because
> > the only way to write it is to read-modify-write the whole fenv. But
> > since we know on x86_64 we have sse registers, we can just move all
> > the flags to the sse register, then use fnclex to clear the x87 one
> > inexpensively, and the effective set of raised flags remains the same.
> 
> I am worried about the lack of consistency.
> 
> What if something that is only using (say) 80-bit floating arithmetic comes
> back looking for a raised exception in the x87 status register &
> MUSL has moved effectively moved it to the mxcsr.

only musl internally has to be cosistent, which it is.

if anything else looks at fpu status it must look at
both x87 and sse status otherwise it will be wrong
no matter what musl does (fp operations are outside
the control of musl and whoever else tries to look
at fpu status)

but i think if something looks at fpu status behind
the libc it's already wrong: libc can implement fe*
however it wants to as long as the behavior follows
the language semantics, so internal hw registers are
meaningless as soon as a libc call is made.

iirc gcc can emit software float code on x86 that
uses the x87 status register to record the soft
float fenv status, so those bits can change even
if there was no hard float instruction, i.e. the
flags make sense on the c language level but not
on the hw level, if you mix those two levels you
are in trouble.