https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #21 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote: > First of all, it is questionable if gcc is still conforming after the change > discussed here and implemented as per gcc 8.0. Yes "an implementation may > accept other forms of constant expressions" but that doesn't mean that a > compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the > definition > of an integer constant expression. So this ought to explicitly be a compiler > extension and we ought to have a way to reliably compile strictly conforming > programs with gcc without constraint violations silently getting ignored. "integer constant expression" does not mean the same thing as "constant expression of integer type". If you use this expression in a context requiring an integer constant expression (case label, bit-field width, array designator in initializer, enum value, array size at file scope, constexpr initializer for object of integer type, etc.), it's properly rejected as required; in contexts where both integer constant expressions and other expressions are valid but with different semantics (e.g. determining whether something is a null pointer constant, determining whether an array is a VLA in a context where both VLA and non-VLA arrays are valid), again it's treated as non-constant.
