clang: constexpr does not honor -fwrapv, leading to compilation error

[markus-oberhumer]

Godbolt link: https://godbolt.org/z/8KhvbcWr6

Reproducible with clang-trunk

$ clang++ -fwrapv -Wno-integer-overflow -c test.cpp
test.cpp:15:16: error: constexpr variable 'b2' must be initialized by a constant expression

$ cat test.cpp
// compile with: clang++ -fwrapv -Wno-integer-overflow -c test.cpp
//
// extra rant: -Wno-integer-overflow should not be needed here!

#include <limits.h>

#define wrap_inc(x)     ((x) + 1 < (x))

constexpr int int_max = INT_MAX;

bool b0 = wrap_inc(int_max);
const bool b1 = wrap_inc(int_max);

// error: constexpr variable 'b2' must be initialized by a constant expression
constexpr bool b2 = wrap_inc(int_max);

[shafik]

We seem to be consistent with gcc in most cases although the bool case stands out, I believe that is a gcc bug b/c that case should be treated the same way, see: https://godbolt.org/z/ad3391Eh3

I believe command line options should not modify whether an expression is considered well-formed in a constant expression or not b/c this has wider impacts on portability due to use in templates and other scenarios that required constant expression such as support for variable length arrays as an extension. Although I will leave it open to allow for more feedback if others want to weigh in.

[markus-oberhumer]

Yes, gcc has a similar but not identical problem/view. Reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861

[jwakely]

I believe command line options should not modify whether an expression is considered well-formed in a constant expression or not b/c this has wider impacts on portability

100% agreed

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[markus-oberhumer]

I believe command line options should not modify whether an expression is considered well-formed in a constant expression or not b/c this has wider impacts on portability

100% agreed

I get your point, but please note that we already have such command line options.

godbolt link: https://godbolt.org/z/5EvdhWha8

// -fsigned-char:   error: constexpr variable 'dummy' must be initialized by a constant expression
// -funsigned-char: valid

constexpr int dummy = (('\377' > 0) -1) << (sizeof(int) * 8 - 1);

[jwakely]

Not the same. The standard says it's unspecified whether char is signed or unsigned. It doesn't say it's unspecified whether INT_MAX+1 is valid.

[markus-oberhumer]

So you're saying that int_max + 1 is invalid per definition, even if my C++ compiler explicitly implements wrapping signed integers?

[shafik]

Unspecified behavior still results in a well-formed program:

behavior, for a well-formed program construct and correct data, that depends on the implementation

Even though unspecified behavior is well-formed it is not portable and developers need to be aware of that and design accordingly.

Undefined behavior is never well-formed. It is a runtime behavior and even though we have command line options to define the behavior at runtime undefined behavior is not allowed in a constant expression:

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:

and includes the following bullet:

an operation that would have undefined behavior as specified in [intro] through [cpp], excluding [dcl.attr.assume];

[markus-oberhumer]

@shafik @jwakely Many thanks for your detailed feedback, so I'd guess this issue can be closed as invalid.