On Friday, 17 September 2021 09:40:52 CEST Matthias Kretz via Ext wrote:
> If those types have the same properties
>
> > (i.e. represent IEEE interchange types), they should be the
> > same from a type system perspective.
>
> Do I read X.6 [2] correctly that all _Float* types must fully support NaN
> and Inf? 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 was a bit too fast...

P1467 § 7.4. "Layout vs. behavior" says (emphasis mine):
  The IEEE-conforming type aliases must have the specified IEEE layout and
*should have the required behavior*.

Which seems to contradict § 5.1:
  It is currently implementation-defined whether or not the floating-point
types support infinity and NaN. That is not changing. That feature will still
be implementation-defined, even for extended floating-point types.

Or I'm reading to much into the word "should". Why not remove the behavior
requirement if all we're asking for is "should"?

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?

FWIW, my strong opinion is that representation and behavior are two mostly
orthogonal features of floating-point types and std::float*_t should only
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.

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