Re: i386 and x86_64 fenv support

["Howland, Craig D. - US via newlib" <newlib@sourceware.org>]

> From: newlib-owner@sourceware.org <newlib-owner@sourceware.org> on behalf of Joel Sherrill <joel@rtems.org>
> Sent: Tuesday, August 27, 2019 1:30 PM
> To: Joseph Myers
> Cc: Newlib
> Subject: Re: i386 and x86_64 fenv support
>
> 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.
That GLIBC requirement violates what the standards say.  C99 says, "Each of
the macros FE_DOWNWARD FE_TONEAREST FE_TOWARDZERO FE_UPWARD is defined if and 
only if the implementation supports getting and setting the represented 
rounding direction by means of the fegetround and fesetround functions."
This GLIBC rule is saying that you have to pretend FE_TONEAREST works, even
when it does not.  It does half of what is required, allowing that value
with the functions, except they don't really do it.  And it also then 
improperly tells code that is the fixed rounding direction, when it really
is not.  So while I can see how GLIBC might have chosen that for expediency,
I think it is a very bad thing.  The best thing would be to not let GCC 
tell there is fenv support when there is not.  We were fine before, but now
the new fenv.h in Newlib breaks that due to this FE_TONEAREST quirk.  So is 
there a way to have the GCC autoconf libquadmath "have fenv?" check fail 
when we're only supplying the stub?  (It seems to me that it really ought to 
fail if FE_TONEAREST is not defined, since that is required.  I'd call it
a GCC bug, but we can at least try to work around it.)
 
Craig