This is the mail archive of the
mailing list for the GCC project.
Re: Start implementing -frounding-math
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Thu, 8 Aug 2019 13:02:43 +0000
- Subject: Re: Start implementing -frounding-math
- Ironport-sdr: OuCyBeDpAPrxYYRwkUK7HTLP+yj8fdKaj5q+ujZ5nVwEcf5L/YBUF/7hP60kQRQLvOqxitzCyx m2vOZFb9FA9z5xafVssJi5+vLVIKu6NfbmcZVhW+cok6EkvXpMBUj4cMMgrMwt/7LuMYr0qsdJ b3Ng386c2jhnXw+WiODvGMrtrzGgWY24ym1DmMPH2jbgbQFoWLW6wiPipI0kjF/CsGonFxGq+Q DwSTvlezeeiR0bIX5NvUbduFXH8i1vDSLMo8AQbgZCDehNKOwGuHoRL+44Vnanh5M0Gf1/kQxv mOo=
- Ironport-sdr: C0n/4ZDbz08QvGiDU0obWskppzBdX1Yytx47dkYZVbegcPOkJg0VcB8xZNoCcrb92G94J89pGh BxSaPzbVaeoa2DD3m7V2dSrMtDX4fWy2PQXXHQXYFwpXDjTctzR1J/4MFmAvf1Ra2LL8AycLG1 tppM2mJdt2Q3BHXk0rK/IZFWw8HpkWr4WxicttTGBlkgS55kZn4e5BpYIiAVKlI/+dvCY6bRJ0 6IakPLOB/ucDOK1bOoA2UY7MksJg9SnY/Q/Hl9BEA4bqOqp7wBZE/N3BIPGk9m/d/P8EAREjGN eWE=
- References: <alpine.DEB.firstname.lastname@example.org> <ADA10368-A011-4D72-BCD0-BA2E38B07EA3@gmail.com> <alpine.DEB.email@example.com> <alpine.DEB.firstname.lastname@example.org> <alpine.DEB.email@example.com>
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
(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