Clang should warn for implementation-defined constant expressions

[Eisenwave]

The following code doesn't compile for all major compilers, but receives no warnings from -Wall -Wpedantic -Wextra:

const float x = 0;
const float y = x;

This code isn't portable, even with the C23 relaxations. GCC and clang allow it, but MSVC rejects it. It is technically legal C, but the portability issues at least deserve a warning.

Relevant Wording

More latitude is permitted for constant expressions in initializers. Such a constant expression shall
be, or evaluate to, one of the following:

• a named constant,
• a compound literal constant,
• an arithmetic constant expression,
• a null pointer constant,
• an address constant, or
• an address constant for a complete object type plus or minus an integer constant expression

- 6.6 Constant expressions p9

For the initialization of y, obviously only the first and third bullets can apply. Arithmetic constant expressions are built on top of named constants, so the only question is whether x is a named constant.

An identifier that is:

• an enumeration constant,
• a predefined constant, or
• declared with storage-class specifier constexpr and has an object type,

is a named constant, as is [...]

- 6.6 Constant expressions p7

x is not a named constant, because it is not constexpr. However, this code is not ill-formed, merely implementation-defined:

An implementation may accept other forms of constant expressions; however, they are not an integer constant expression.

- 6.6 Constant expressions p14

Suggested Solution

Clang should issue a warning, along the lines of:

initialization of 'y' relies on implementation-defined constant expressions [-Wnon-portable-constexpr]

[llvmbot]

@llvm/issue-subscribers-c

[AaronBallman]

By the same logic, this should also happen in C++ as well (for example, when hitting implementation-defined limits: http://eel.is/c++draft/expr.const#5.7).

[llvmbot]

@llvm/issue-subscribers-c-1

[Eisenwave]

By the same logic, this should also happen in C++ as well (for example, when hitting implementation-defined limits: http://eel.is/c++draft/expr.const#5.7).

That's arguably also an issue, and a warning could be issued when guaranteed implementation limits are exceeded.

Generally though, exceeding some implementation-defined numeric limit is less significant than relying on what is spiritually a compiler extension.

[AaronBallman]

I think the value of these diagnostics is for code portability, so implementation limits, use of extensions, conditionally supported features, and implementation-defined behavior all seem like fair game for the same warning group, though we would want individual knobs for controlling diagnostics under that group. The one scenario that I think we wouldn't diagnose would be when the behavior is common to all of the major implementations (e.g., we all assume int is 32 bits on certain architectures; warning about portability for that is overkill). (There's definitely some amount of "severity level" involved -- extensions are less portable than conditionally supported features, some impl-defined behaviors are quite portable, etc. So perhaps there's more ways to group these together.)

[frederick-vs-ja]

That's arguably also an issue, and a warning could be issued when guaranteed implementation limits are exceeded.

I'm afraid that the implementation limit doesn't seem to be guaranteed. IIUC 1048576 is merely a recommended value and a conforming implementation can defined it to 512 or even smaller...

[AaronBallman]

That's arguably also an issue, and a warning could be issued when guaranteed implementation limits are exceeded.

I'm afraid that the implementation limit doesn't seem to be guaranteed. IIUC 1048576 is merely a recommended value and a conforming implementation can defined it to 512 or even smaller...

Correct, it is a recommended value (not mandated for conformance), but we can still diagnose when the recommendation is exceeded if we choose. For compilers we aim to be compatible with (MSVC, GCC), we could also explore tracking their limits separately from the recommended ones (e.g., a GCC compat specific warning vs a general implementation limit exceeded warning).