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 jos...@codesourcery.com
