Re: i386 and x86_64 fenv support

[Joel Sherrill <joel at rtems dot org>]

On Tue, Aug 27, 2019 at 12:11 PM Joseph Myers <joseph@codesourcery.com> 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
> joseph@codesourcery.com