On Fri, Sep 17, 2021 at 5:03 AM Matthias Kretz via Ext
<ext_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.
>
> 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.

FWIW, it's sounding more and more to me like there's high risk for
user confusion and incompatibilities between C and C++ in this space
and we should consider a joint meeting with the C Floating Point Study
Group to see what can be done in both committees to reduce that
likelihood. I'm planning to discuss P1467 in SG22 on Oct 1, and I will
invite the CFP group (as well as others in WG14) to attend.

~Aaron

>
> --
> ──────────────────────────────────────────────────────────────────────────
> Dr. Matthias Kretz https://mattkretz.github.io
> GSI Helmholtz Centre for Heavy Ion Research https://gsi.de
> stdₓ::simd
> ──────────────────────────────────────────────────────────────────────────
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2021/09/17656.php