On Fri, Sep 17, 2021, 3:02 AM Matthias Kretz <m.kretz_at_[hidden]> wrote:

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

You are mixing together a section that talks about specific types named in
the namespace std ("the ieee conforming type aliases") and a section that
talks about floating point types at large. If an implementation does not
support inf and nan, it would not define the ieee conforming type aliases.


> 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
> ──────────────────────────────────────────────────────────────────────────
>