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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.