On 11/8/21 5:56 AM, Vincent Lefevre wrote:
> In article <smah3q$a9f$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>
>> On 11/7/21 9:44 PM, Vincent Lefevre wrote:...
>>> These rules are not about overflow. They are general rules.
>
>> Yes, and they are sufficiently general that it is perfectly clear how
>> they apply to the case when there is overflow.
>
> I've done some tests, and it is interesting to see that both GCC and
> Clang choose the IEEE 754 definition of overflow on floating-point
> constants, not yours (<sl9bqb$hf5$2@dont-email.me>).

The only definition for overflow that I discussed is not mine, it
belongs to the C standard: "A floating result overflows if the magnitude
(absolute value) of the mathematical result is finite but so large that
the mathematical result cannot be represented without extraordinary
roundoff error in an object of the specified type." (7.12.1p5).

> ... For instance,
> the exact value of 0x1.fffffffffffff7p1023 is larger than DBL_MAX,
> but it doesn't trigger an overflow warning with GCC and Clang.

No warning is mandated for overflows, so that doesn't contradict
anything I said.

I wasn't talking about overflow for it's own sake, but only in the
context of what the standard says about the value of floating point
constants. What value does that constant have? Is it one of the three
values permitted by 6.4.4.2p4? Is it, in particular, the value required
by IEEE 754? If the answers to both questions are yes, it's consistent
with everything I said.

>>> What is not defined is when a value overflows (there are different
>>> definitions). And what is the consequence of the overflow (at runtime,
>>> there may be traps).
>
>> We're talking about floating point constants here. The standard clearly
>> specifies that "Floating constants are converted to internal format as
>> if at translation-time. The conversion of a floating constant shall not
>> raise an exceptional condition or a floating-point exception at
>> execution time." Runtime behavior is not the issue, and traps are not
>> allowed.
>
> I agree. But the question is whether the compiler may choose to
> stop the compilation.

I don't remember that issue having previously been raised.

"The implementation shall not successfully translate a preprocessing
translation unit containing a #error preprocessing directive unless it
is part of a group skipped by conditional inclusion." (4p4).

"The implementation shall be able to translate and execute at least one
program that contains at least one instance of every one of the
following limits:" (5.2.4.1p1).

In all other cases, stopping compilation is neither mandatory nor
prohibited.

> There is a confusion in the standard, because 6.4.4p2 says
> "the value of a constant" while "value" is defined by 3.19
> and means the value of the object, while I suspect that
> 6.4.4p2 intends to mean the *exact* value.

The term "representable value" is used in 23 places in the standard,
including 6.4.4.2p4. That term would be redundant if the term "value"
only had meaning when it could be represented. That interpretation would
render all 23 of those clauses meaningless, including 6.4.4.2p4.

The standard frequently uses the term "value" to refer to the
mathematical value of something, which isn't necessarily representable
in any type, and in particular, need not be representable in the
particular type relevant to the discussion. This is usually done in the
context of defining how the requirements imposed by the C standard
depend upon whether or not the mathematical value is representable or in
the range of representable values, as is the case in 6.4.4p2.

I will agree that it would be clearer to either modify the definition of
"value" to include such usage, or to define and consistently use some
other term (such as "mathematical result", which is used for this
purpose only in the discussions of floating point overflow and underflow).

Note that IEEE 754 uses the same idea in it's description of overflow:
"...by what would have been the rounded floating point result were the
exponent range unbounded."

....
>> The standard describes two cases: if infinities are supported (as they
>> necessarily are when IEEE formats are used), INFINITY is required to
>> expand to a constant expression that represents positive or unsigned
>> infinity. This is not outside the range of representable values - that
>> range includes either positive or unsigned infinity, so the constraint
>> in 6.4.4p2 is not violated.
>
> The range includes all real numbers, but not infinities.

For an implementation that supports infinities (in other words, an
implementation where infinities are representable), how do infinities
fail to qualify as being within the range of representable values? Where
is that exclusion specified? Such formats correspond to affinely
extended real number systems, which differ from ordinary real number
systems by including -infinity and +infinity. IEEE 754 specifies that
infinities are to be interpreted in the affine sense.

> ... No issues
> with INFINITY, but my remark was about the case a user would write
> a constant like 0x1.0p1024 (or 1.0e999). Such constants are in the
> range of floating-point numbers (which is the set of real numbers in
> this case), but this constant overflows with the IEEE 754 meaning,

It also overflows with the C standard's meaning.

> and both GCC and Clang emits a warning for this reason.
>
> Note that if the intent were "exceeds the range", the C standard
> should have said that.

I'm sorry - I seem to have lost the thread of your argument. In which
location in the current standard do you think the current wording would
need to be changed to "exceeds the range", in to support my argument?
Which current phrase would need to be replaced, and why?

>> If infinities are not supported (which is therefore necessarily not an
>> IEEE format), then INFINITY is required to expand to a constant that
>> will overflow. This does violate that constraint, which means that a
>> diagnostic message is required.
>
> This point is not clear and does not match what implementations
> consider as overflow.

Which implementations did you test on, which don't support infinities,
in order to justify that conclusion? In my experience, such
implementations are rare. The only systems I've ever used that didn't
support infinities, failed to do so because they didn't support floating
point at all.

....
> I think that I was initially confused by the meaning of "value".
> in 6.4.4p2, as it seems to imply that a converted value may be
> outside the range of representable values.

Correct. This is an example of a context where it is referring to the
mathematical value, rather than a necessarily representable value.

> ... It seems that it was
> written mainly with integer constants in mind.

I think not - constants with a value that cannot be represented occur in
integer constants, floating constants, and character constants, which is
why that paragraph appears in 6.4.4p2. If it were meant only for integer
constants, it would have been under 6.4.4.1.

> But there's still the fact that "overflow" is not defined (this
> term is used only when there are no infinities, though).

7.12.1p5 is not marked as a definition for "overflows", but has the form
of a definition. There is no restriction within 7.12.1 to
implementations that don't support infinities.

>> However, I'm confused about how this connects to the standard's
>> definition of normalized floating-point numbers: "f_1 > 0"
>> (5.2.4.2.2p4). It seems to me that, even for the pair-of-doubles format,
>> LDBL_MAX is represented by a value with f_1 = 1, and therefore is a
>> normalized floating point number that is larger than LDBL_NORM_MAX,
>> which strikes me as a contradiction.
>
> Note that there is a requirement on the exponent: e ≤ e_max.

Yes, and DBL_MAX has e==e_max.

....
>>> But what is allowed is not clear for an IEEE 754 format (this does
>>> not affect the INFINITY macro, but users could write exact values
>>> larger than DBL_MAX + 1 ulp, for which nextdown(DBL_MAX) could be
>>> unexpected as the obtained value).
>
>> It's unexpected because that would violate a requirement of IEEE 754,
>> but the C standard doesn't require violating that requirement. Section
>> 6.4.4.2p4 of the C standard allows such a constant to have any one of
>> the three values (+infinity, FLT_MAX, or nextdownf(FLT_MAX)).
>> Therefore, an implementation that wants to conform to both the C
>> standard and IEEE 754 must select FLT_MAX. What's unclear or ambiguous
>> about that?

I had originally intended that paragraph to be about INFINITY, where
FLT_MAX is the relevant limit, but you were explicitly talking about
DBL_MAX+1ulp, so I should have changed all instances of FLT in that
paragraph to DBL_MAX.

> If Annex F is not claimed to be supported[*], this requirement would
> not be violated.

And if Annex F were claimed to be supported, this requirement would
still not be violated by giving that constant a value of DBL_MAX. That
value satisfies all applicable requirements of either standard.