Suggestion on implementation of floating-point computations with different rounding mode

programmerjake: > they are already unsound on some targets because some of the fp operations are implemented by changing the rounding mode and then changing it back, e.g. converting float to integer on i586-unknown-linux-gnu without additional target features works by temporarily changing the rounding mode using fldcw to round-towards-zero, converting to an integer using fistp, and then changes the rounding mode back using another fldcw. Oh, interesting. Always exciting to learn about new ways in which the non-SSE x86-32 targets are broken... Vorpal: > What about interrupt handlers or (as Alice pointed out) signal handlers? Do all targets guarantee that FP flags are saved/reset/restored when those happen? I'm pretty surr that isn't the case on embedded ARM at least, but maybe it is on Linux and similar. Yeah I hope they guarantee that, everything else sounds kind of broken. Vorpal: > The fact that this is stateful on most architectures is pretty bad. Yes, global state is bad. Sadly hardware engineers love global state so here we are... Vorpal: > Sorry, i somehow missed the last paragraph of your post. But it doesn't seem feasible to add this (safely) without declaring existing code for interrupt handlers unsound. That doesn't seem compatible with the Rust backward compatibility guarantee. I think it is already generally understood that it's fine to temporarily change the rounding mode in an inline asm block as long as you change it back before returning from that block. So I would argue that any setup where interrupt handlers inherit the rounding mode from whatever previous code that ran is already using a non-standard contract and has to manually ensure that all the code they link in will never change the rounding mode.