Re: i386 and x86_64 fenv support
Joel Sherrill <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAF9ehCXyEbaciR0b2YSh4HaoUBbFN546u61H8xL8D6uvusppjA@mail.gmail.com> |
On Tue, Aug 27, 2019 at 12:11 PM Joseph Myers <[email protected]> wrote: > > On Tue, 27 Aug 2019, Joel Sherrill wrote: > > > FWIW this moved up in importance because the x86_64 RTEMS toolchain > > won't build with the gcc/newlib master because libquadmath assumes the > > existence of the FE_TONEAREST since it the autoconf probe now sees > > we have fenv.h support now. This is probably a bug in this code since it > > can't assume a rounding mode is supported. > > The rule in glibc is that architectures without support for rounding modes > still define FE_TONEAREST, and return it from fegetround and accept it for > fesetround, reflecting that to-nearest is the default (and only) rounding > mode. > > That is, only architectures that don't support to-nearest at all should > fail to define FE_TONEAREST (and libquadmath doesn't support any such > architectures anyway). So the stub version should define FE_TONEAREST, return 0 if that's the input to fesetround, and return FE_TONEAREST from fegetround? The discussion when the behavior was picked was to match soft float. But we could have easily missed something. There are other FE_xxx constants used in libquadmath/math and I haven't looked at them in detail but grep output looked like they were all wrapped in ifdef's. --joel > > -- > Joseph S. Myers > [email protected]