Date: Fri, 17 Sep 2021 14:37:40 +0000
On Fri, 17 Sep 2021, Matthias Kretz via Liaison wrote:
> I'd be wary of asking for full IEC 60559 behavioral conformance for
> std::float*_t. Does this extend to <cmath>, i.e. require correctly rounded
> implementations of all cmath functions?
C distinguishes two classes of functions: those fully bound to IEC 60559
operations, required to produce correctly rounded results with
corresponding exceptions when Annex F is implemented, and those not bound
to IEC 60559 operations, which have weaker requirements (and corresponding
reserved cr_* names that can be used for correctly rounded variants). See
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2749.pdf (accepted at the
last WG14 meeting).
> require IEC 60559 representation at this point. At some point we need to have
> a good talk about behavior and how to get back control over the fast-math
> optimizations we want and don't want compilers to perform. But that needs
> proper exploration.
Note that TS 18661-5 defines pragmas that allow a limited set of
optimizations, but it's not being added to C23 and I'm not sure there's
any implementation experience of it (certainly not enough to be confident
of whether it's a good approach or not).
> I'd be wary of asking for full IEC 60559 behavioral conformance for
> std::float*_t. Does this extend to <cmath>, i.e. require correctly rounded
> implementations of all cmath functions?
C distinguishes two classes of functions: those fully bound to IEC 60559
operations, required to produce correctly rounded results with
corresponding exceptions when Annex F is implemented, and those not bound
to IEC 60559 operations, which have weaker requirements (and corresponding
reserved cr_* names that can be used for correctly rounded variants). See
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2749.pdf (accepted at the
last WG14 meeting).
> require IEC 60559 representation at this point. At some point we need to have
> a good talk about behavior and how to get back control over the fast-math
> optimizations we want and don't want compilers to perform. But that needs
> proper exploration.
Note that TS 18661-5 defines pragmas that allow a limited set of
optimizations, but it's not being added to C23 and I'm not sure there's
any implementation experience of it (certainly not enough to be confident
of whether it's a good approach or not).
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-09-17 09:37:55