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.

Also, _Float32x, _Float64x and _Float128x must meet the IEEE 754
definition of extended formats. That includes the relation between emin
and emax, although the specific representation is unspecified. (Thus, the
x86 "extended" format is a valid implementation of _Float64x. But the
m68k variant of that format is *not* a valid implementation of _Float64x,
because it has an emin value 1 smaller than that for the x86 format, so
fails to satisfy the relation between emin and emax.)

> 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).

-- 
Joseph S. Myers
joseph_at_[hidden]