[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > int_max+1 is not a core constant (C++20 7.7 [expr.const] paragraph 5, bullet oops, s/core constant/core constant expression/ > 5.7), so is not usable as

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #7 from Jonathan Wakely --- (In reply to Markus F.X.J. Oberhumer from comment #6) > Please note that I'm explicitly using "int_max" and not "INT_MAX", It's a constexpr variable with the same value, so that makes no difference

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread markus at oberhumer dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #6 from Markus F.X.J. Oberhumer --- Please note that I'm explicitly using "int_max" and not "INT_MAX", and I'd appreciate if you could give me a link where the standard says this is "ill-formed". Thanks!

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #5 from Jonathan Wakely --- To expand on that, the standard allows compilers to do anything for undefined behaviour, including making it valid with well-defined semantics. So wrapping for undefined overflow is a conforming

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #4 from Jonathan Wakely --- Andrew is right. The C++ standard says this is ill-formed, the -fwrapv option isn't allowed to change that. The option means that runtime overflow is well-defined instead of undefined, but that doesn't

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread markus at oberhumer dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #3 from Markus F.X.J. Oberhumer --- Indeed. And just for reference I had also reported this as clang bug in https://github.com/llvm/llvm-project/issues/59195

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #2 from Andrew Pinski --- Note clang rejects even just: #include #define wrap_inc(x) ((x) + 1 < (x)) constexpr int int_max = INT_MAX; bool b0 = wrap_inc(int_max);

[Bug c++/107861] C++ static_assert() does not honor -fwrapv, leading to compilation error

2022-11-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107861 --- Comment #1 from Andrew Pinski --- Right, this is by design and I don't think it is a bug. The reasoning is the C++ constant expressions have a way of requiring you to having to figure out if it was going to overflow and cause different