CWG2752 Excess-precision floating-point literals

[jensmaurer]

In C23, floating-point literals (called "constants" there) can be represented with excess precision, meaning a float literal is treated as a double or long double value (without affecting the type system, though).

In C++, there is no such permission.

Both C++ and C permit floating-point computations (including operands) to use excess precision. A footnote hints that a conversion will drop the excess precision (e.g. (float)(314.f/100.f) yields a value with float precision) (like C does), but there is no normative wording to make that happen.

What is the design intent for handling excess-precision floating-point computations in C++?

See CWG2752 for details.

[jfbastien]

SG6 input is desired, please assign to EWG afterwards.

[mattkretz]

2023-11-07 SG6 Minutes

Chair: Matthias Kretz

Minute Taker: Philip Craig

Summary

The issue is asking

What is the design intent for handling excess-precision floating-point
computations in C++?

Nobody in SG6 felt qualified to answer this question from an "original design
intent" perspective. So the question was interpreted as stating design intent
as required by numerics users. There was no consensus for a desired behavior
and it appears that a more thorough exploration in a paper would be necessary
to aid the discussion.

Polls

1. Compilers need to be allowed to use the x87 FPU for computation and
   comparison (without "too much" intermediate rounding)

POLL: C++ should not deviate from C in how floating-point behaves (excess
precision, fp contraction, literals)

SF	F	N	A	SA
0	3	1	1	1

# of Participants: 7
Outcome: No consensus for change
Comments: We could really use a paper to make a more informed decision. The
paper would need to explore the consequences of all the different options.

Polls considered, but not taken without a better understanding of the
consequences:

POLL: The C++ standard should allow floating-point contraction into FMAs by
default.

(We disagreed on whether the current wording in [expr.pre] allows fp
contraction. Therefore, there was no clear "status-quo" position.)

POLL: There needs to be a standard-conforming way to control floating-point
contraction.