April 19, 2026, 11:06am 1

Hello everyone!

Some FPUs support changeable settings and status flags that affect (and are affected) by floating-point operations, known as floating-point environment. This includes rounding mode and floating-point exceptions, as well as "denormals-are-zero" and other settings supported by some hardware. Currently, behavior of Rust program running in non-default floating-point environment (such as non-default rounding mode, enabled "denormals-are-zero" mode or unmasking any floating-point exceptions) is undefined, and floating-point exception status flags may have meaningless value. I wonder, what about Rust programs compiled in software floating-point emulation mode (soft-float)? Can its behavior become undefined solely because of unexpected floating-point environment, and can it affect floating-point exceptions in an unexpected way (that may be important if, for example, hardware floating-point computations are done with inline assembly)?

I would assume that (for those platforms where soft-float compilation even exists), the equivalent properties should be true as well: If you were to somehow manage to modify any global state of the soft-float implementation being linked (if it even has any state; I don’t actually know) then that would be similarly UB unless the modifications were contained to within a single inline-assembly block. If you merely modify the FPU status (assuming the chip has an FPU, but you compiled your code in such a way that it doesn’t use the FPU but soft-float instead) then that should probably be harmless (but also arguably a weird setup).

That being said, I don’t actually know how realistic any access to the soft-float implementation even is in the first place, nor whether or not it features global state that could be messed with. Perhaps you know that better than me? Or maybe you meant something entirely different with your question? Also, for looking at concrete examples maybe, do you have some concrete hardware/architecture in mind?