https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121570
--- Comment #12 from kargls at comcast dot net --- (In reply to Francois-Xavier Coudert from comment #10) > The first implementation of the IEEE modules intended to be erring on the > side of cautiousness, so I added systematic code to save and restore the FP > status. > > Indeed, it may be that some IEEE intrinsics can be translated directly into > a standard libc function call, and where the expectations of the Fortran > standard and IEEE language match the guarantees of the libc function, we > could avoid saving/restoring FP state. It may even be that it is the case > for most of these intrinsics. > > I would only warn to be cautious, and my reasoning for this is: there are > other Fortran intrinsics to achieve the same goal with lot more relaxed > requirements about exceptions and flags and special values. And most people > use those. But when people use the IEEE intrinsics, it probably means they > really expect conforming behavior :) Thanks for confirming my suspicions about being overly cautious. I suspect I would have made the same decision. In your 2nd reply, it seems that most of the functions that you did not wrap do not do any actual FP computations, e.g., ieee_is_normal is only checking man if a value is normal. I suppose we could remove the save/restore of fpu state in IEEE_LOGB, IEEE_RINT, IEEE_REM, and IEEE_NEXT_AFTER see what the fallout will be. As you note, people using the IEEE module likely know what they are doing, and so, they'll quickly point out the error in the change. On amd64-*-freebsd, IEEE_RINT and IEEE_REM are in-lined. IEEE_LOBG generates a call to logbf(), and IEEE_NEXT_AFTER generates a call to nextafter().
