C++ Logo


Advanced search

Re: [wg14/wg21 liaison] [isocpp-ext] Report from the recent C/C++ liaison meeting (SG22); includes new floating point types(!)

From: Matthias Kretz <m.kretz_at_[hidden]>
Date: Fri, 17 Sep 2021 09:40:52 +0200
On Thursday, 16 September 2021 23:42:56 CEST Jens Maurer wrote:
> On 16/09/2021 23.00, Matthias Kretz via Liaison wrote:
> > After reading Section 8 "Conversions" in N2601 (WG14),

Oh, I was actually reading the TS document (Part 3) ...

> > I believe
> > std::floatN_t and _FloatN need to be distinct types anyway. P1467R4 says
> > "The proposed usual arithmetic conversions when mixing different
> > floating-point types are>
> > essentially the same in both languages". But I read it differently:
> > float + _Float32 -> _Float32
> > float + std::float32 -> float.
> Not good.
> Remarkably, the result for "double" seems to be the other way round under
> N2601:
> double + _Float64 = double
> per section X.4.2 (page 10 line 17).

No, line 11 should take precedence. _Float64 is an interchange floating type,
so "the other operand is converted, without change of type domain, to a type
whose corresponding real type is that same interchange floating type".

I read N2601 to do the following (assuming float and _Float32 as well as
double and _Float64 have equivalent sets of values):

  float + _Float32 -> _Float32
  double + _Float64 -> _Float64
  float + _Float64 -> _Float64
  double + _Float32 -> double
if the sets of values of _Float64x and long double are equivalent:
  long double + _Float64x -> long double
if the sets of values of _Float64x and double are equivalent:
  double + _Float64x -> double

> > Would it be an option to keep _Float32 and std::float32 distinct types?
> That seems unhelpful. 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"?

C and C++ may be defining the same types in terms of binary representation.
But the C and C++ committees might have different semantics in mind. If I
understand the C specification correctly, we should probably have a dedicated
meeting about floating-point semantics where we invite the C FP group ...

 Dr. Matthias Kretz           │ SDE — Software Development for Experiments
 Senior Software Engineer,    │ 📞 +49 6159 713084
 SIMD Expert,                 │ 📧 m.kretz_at_[hidden]
 ISO C++ Committee Member     │ 🔗 mattkretz.github.io
GSI Helmholtzzentrum für Schwerionenforschung GmbH
Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de
Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528
Managing Directors / Geschäftsführung:
Professor Dr. Paolo Giubellino, Dr. Ulrich Breuer, Jörg Blaurock
Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats:
Ministerialdirigent Dr. Volkmar Dietz

Received on 2021-09-17 02:41:00