Hi FX, This looks fine to me. OK for trunk.
I am not sure how you communicate the IEEE support to the front, since you need to be able to support cross-compilation. I identification of the hardware architecture sufficient? Cheers Paul On 6 August 2015 at 18:11, FX <fxcoud...@gmail.com> wrote: > The attached patch fixes the only remaining IEEE bug (to my knowledge) in > gfortran. > > A Fortran 2008 interpretation request was submitted two years ago about which > of the IEEE functions were supposed to be used in constant and specification > expressions. The interp, voted on by J3 in Nov 2014, made corrections to the > standard (see my comment at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64104#c3 for the detail of > this). This front-end patch makes gfortran conforming with the standard. > > There is a minor caveat: since support for various kinds (results of the > IEEE_SELECTED_REAL_KIND, IEEE_SUPPORT_ROUNDING, IEEE_SUPPORT_FLAG and > IEEE_SUPPORT_HALTING functions) are detected at runtime, we need in the > future a mechanism to communication the support detected in libgfortran back > to the front-end. The current approach does not do that, but instead assumes > that if IEEE modules are present, support is enabled for all flags and > rounding modes. This is true on the common platforms (x86 and x86_64), so I > guess it’s good enough to enable it now. In the meantime, I’m thinking about > how best to achieve the long-term goal (spec file? secret logical constants > in the IEEE modules?) for the future. > > Bootstrapped and regtested on x86_64-apple-darwin14. OK to commit to trunk? > > FX > > > > -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
