On Friday, 17 September 2021 16:33:27 CEST Joseph Myers wrote:
> On Fri, 17 Sep 2021, Matthias Kretz via Liaison wrote:
> > Do I read X.6 [2] correctly that all _Float* types must fully support NaN
> > and Inf?
>
> Yes.
> [...]
>
> > Whereas P1467 intends to leave NaN and Inf support implementation-
> > defined? Consequently, a feature like -ffinite-math-only would have to
> > disable Annex X support in the compiler / only apply to "standard
> > floating types"?
>
> I think of -ffinite-math-only as being a "non-conforming mode" option
> (effectively it introduces undefined behavior whenever any non-finite
> floating-point representation is used, and while an implementation can
> always define such representations as trap representations in the absence
> of Annex F / Annex X support, that's only sufficient to yield undefined
> behavior when they are read from memory, not for standard functions that
> are required to return some implementation-defined value, or HUGE_VAL, on
> error cases for types with only finite values, rather than a trap
> representation - a conforming -ffinite-math-only option would need to make
> those functions actually return finite values).

I guess you're right. I always considered -ffinite-math-only conforming, since
it doesn't define __STDC_IEC_559__ and thus doesn't claim to implement Annex
F. That doesn't seem to be enough. The compiler would have to remove inf and
nan from the set of values of the real floating types and consequently
HUGE_VAL couldn't be an inf representation anymore. Or `int isinf(real-
floating) { return 0; }` seems to be enough to make
-ffinite-math-only non-conforming to 7.12.3.3.

OK that certainly weakens my position...

-- 
──────────────────────────────────────────────────────────────────────────
 Dr. Matthias Kretz                           https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research               https://gsi.de
 stdₓ::simd
──────────────────────────────────────────────────────────────────────────