[C23] constexpr incorrectly rejects infinity and nan

[AaronBallman]

Consider:

constexpr float inf = 1.0f / 0.0f;
constexpr float nan = 0.0f / 0.0f;

Clang currently rejects these, while GCC accepts: https://godbolt.org/z/oG4sP9TMc

I believe Clang is wrong to reject, per C23 6.5.6p6-7 for division, 5.2.5.3.3p19 for infinity being a valid value, 6.7.2p5-6 for constexpr requirements, and 6.6p4 for constant initialization requirements.

Note, __builtin_inff() and __builtin_nan() both work as an initializer for a constexpr variable.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Aaron Ballman (AaronBallman)

Consider: ``` constexpr float inf = 1.0f / 0.0f; constexpr float nan = 0.0f / 0.0f; ``` Clang currently rejects these, while GCC accepts: https://godbolt.org/z/oG4sP9TMc

I believe Clang is wrong to reject, per C23 6.5.6p6-7 for division, 5.2.5.3.3p19 for infinity being a valid value, 6.7.2p5-6 for constexpr requirements, and 6.6p4 for constant initialization requirements.

Note, __builtin_inff() and __builtin_nan() both work as an initializer for a constexpr variable.

[AaronBallman]

Whoops, poor reading comprehension on my part; the division by zero is UB even for floating-point values. 6.5.6p6 has a second sentence that matter:

The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined.

[AaronBallman]

I reopened the issue because C doesn't have a prohibition against undefined behavior in a constexpr initialization, it only requires that the values be exactly representable and a valid constant expression.

C23 6.7.2p5:
An object declared with storage-class specifier constexpr or any of its members, even recursively, shall not have an atomic type, or a variably modified type, or a type that is volatile or restrict qualified. An initializer of floating type shall be evaluated with the translation-time floating-point environment. The declaration shall be a definition and shall have an initializer.124) The value of
any constant expressions or of any character in a string literal of the initializer shall be exactly representable in the corresponding target type; no change of value shall be applied.125)

p6

If an object or subobject declared with storage-class specifier constexpr has pointer, integer, or arithmetic type, any explicit initializer value for it shall be null,126) an integer constant expression, or an arithmetic constant expression, respectively. If the object declared has real floating type, the initializer shall have integer or real floating type. If the object declared has imaginary type, the initializer shall have imaginary type. If the initializer has decimal floating type, the object declared shall have decimal floating type and the conversion shall preserve the quantum of the initializer. If the initializer has real type and a signaling NaN value, the unqualified versions of the type of the initializer and the corresponding real type of the object declared shall be compatible.

And 6.6 doesn't say that something can't be UB, only that it has to be in-range. 6.6p4:

Each constant expression shall evaluate to a constant that is in the range of representable values for its type.

[efriedma-quic]

The C standard might not say we have to reject UB in constant expressions... but it also doesn't say we have to accept UB in constant expressions. (Probably the C standard should be fixed to be more similar to C++ in this respect.)

The C and C++ standards should be revised to allow FP divide by zero; it's complete nonsense that the standards still consider it UB.

[AaronBallman]

The C and C++ standards should be revised to allow FP divide by zero; it's complete nonsense that the standards still consider it UB.

If conforming to Annex F, it's well-defined and life is okay (at least in C, thanks to DR442). Our trouble is 1) we don't claim to conform to Annex F on any target (we should be improving this IMO), and 2) there are targets for which we will almost certainly never conform to Annex F (32-bit x86 without SSE2).

But yeah, I think fp division by zero should be required to not be UB if the target supports an infinity of floating-point type.

[AaronBallman]

The C standard might not say we have to reject UB in constant expressions... but it also doesn't say we have to accept UB in constant expressions. (Probably the C standard should be fixed to be more similar to C++ in this respect.)

Heh, I was going to say "if the code is conforming, we have to accept it", but you're right, once there's UB, the standard goes out the window and there is no conformance to worry about, so we can do what we want. So this is a good point!

[AaronBallman]

I raised the question on the WG14 reflectors and the response was:

The CFP group has reviewed the issue and has this to say:

3.5.3 (undefined behavior) #2 says:

Note 1 to entry: Possible undefined behavior ranges from ignoring the
situation completely with unpredictable results, to behaving during
translation or program execution in a documented manner characteristic
of the environment (with or without the issuance of a diagnostic
message), ...

This would seem to mean an implementation that does not declare
support for Annex F but that does document its support for infinity
could set f to +infinity without issuing a diagnostic message.

So Clang could match GCC's behavior and begin to accept these.