https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Sep 09, 2019 at 07:22:24PM +0000, wdijkstr at arm dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91690 > > Wilco <wdijkstr at arm dot com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |wdijkstr at arm dot com > > --- Comment #6 from Wilco <wdijkstr at arm dot com> --- > (In reply to Steve Kargl from comment #5) > > On Mon, Sep 09, 2019 at 06:25:53PM +0000, wilco at gcc dot gnu.org wrote: > > > > > > > > The Fortran standard may require this behavior. 18-007r1 page 435 > > > > > > But none of that is needed since a correct implementation of isnan > > > etc does not affect the floating point state at all (see PR66462). > > > > > > > OK. So you can special case IEEE_IS_NAN(). What about > > the other IEEE_ARITHMETIC functions? > > The same is true for the other isxxx functions from C99 and the new iszero and > isdenormal. Are there other functions besides these in IEEE_ARITHMETIC? Don't know. I haven't tried cross-referencing C99 against Fortran 2018. Table 17.2i lists the functions made available by IEEE_ARITHMETIC. > > PR66462 has been re-opened. Tamir seemed to have developed > > 4 different patches, yet no one can agree on "a correct > > implementation" for all targets. > > As his latest comments explain, Tamar's last patch is correct. That should be > the default since an integer implementation which doesn't affect floating > point > state is the only correct one. It happens to be the fastest as well as a > bonus. > > Either way, I don't believe the Fortran front-end should try to work around > mid-end bugs. As reported a save/restore is prohibitive expensive on all > targets so shouldn't even be contemplated. The saving and restoring FPU state was implemented in troutmask:sgk[206] svn log -r 216036 ------------------------------------------------------------------------ r216036 | fxcoudert | 2014-10-09 02:47:25 -0700 (Thu, 09 Oct 2014) | 25 lines The above is a full 8 months before PR66462. PR66462 was opened on 2015-06-08. A patch was committed on 2017-06-08 and the PR was closed. PR66462 was re-opened on 2017-06-09. The patch seems to have been reverted in r249050, but this action isn't recorded in the PR. Tamar's last comment #19 contains "Yes it was committed and reverted and fixed, but never committed again." So, it seems that the Fortran FE isn't trying to workaround anything. It is seemingly trying to ensure the requirements of the Fortran standard are met. If and when someone has the time to review the implementation IEEE_ARITHMETIC, perhaps, the saving/restoring of fpu state can be addressed.
