Start implementing -frounding-math

[Joseph Myers]

On Thu, 8 Aug 2019, Marc Glisse wrote:

> > FENV_ROUND (and FENV_DEC_ROUND) shouldn't be that hard, given the
> 
> On the glibc side I expect it to be a lot of work, it seems to require a
> correctly rounded version of all math functions...

No, it doesn't.  18661-4 reserves cr* names for correctly rounded 
functions; most of the non-cr* names are not bound to the IEEE operations 
and so have no specific accuracy requirements, with FENV_ROUND they just 
need to behave the same as if the relevant dynamic rounding mode were set 
(via the compiler temporarily setting it before calling the function).

> It seems that hex floats are accepted even in C89 with a pedwarn that can be

Not for -std=c90 (since accepting p+ or p- as part of a pp-number would 
change the semantics of some valid C90 programs, see 
gcc.dg/c90-hexfloat-2.c), only -std=gnu* and C99 and later standards.

> We could also have #pragma fenv_round to_nearest (not the exact syntax) in
> float.h, although the C standard doesn't seem to have a push/pop mechanism to
> restore fenv_round at the end of the file.

Also, what's relevant is the state when the macro is expanded, not when 
it's defined.

(The math.h M_* constants aren't a big issue; at most maybe they need a 
few more digits so the constant rounds the same as the underlying 
irrational number in all rounding modes.  The float.h constants are an 
issue precisely because the values are dyadic rationals but need many 
decimal digits to represent them exactly in decimal.)

-- 
Joseph S. Myers
joseph@codesourcery.com