On Friday, 17 September 2021 15:44:49 CEST Michał Dominiak wrote:
> 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.

OK, so the paper meant to say: The IEEE-conforming type aliases must have the
specified IEEE layout and must follow the semantics required by IEC 60559?

FWIW that would make me strongly opposed to P1467 for the reasons stated
below.

Note that there are two levels of "supporting inf and nan":
1. Whether the type as representations for inf and nan;
2. Whether the behavior of producing inf and nan as well as on inf and nan
inputs is well-defined.

std::numeric_limits only reflects the first level. Thus
numeric_limits<std::float32_t>::is_iec559 is true even if the compiler does
not support the inf and nan semantics of IEC 60559.

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