https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #24 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Thu, 23 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote: > In this code > > static const int y = 1; > static int x = y; > > y is not an integer constant expression, nor is it an integer constant in the > meaning that ISO 9899 defines it. Correct, but irrelevant, since nothing in that code example is required by the standard to be an integer constant expression. > Therefore an initializer was given which is > not a constant expression. No, it's an "other form of constant expression" accepted by GCC. > "an implementation may accept other forms of constant expressions" does not > mean that an implementation can throw out any constraints it pleases out the > window. Correct. The Constraints on constant expressions say "Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a subexpression that is not evaluated." and "Each constant expression shall evaluate to a constant that is in the range of representable values for its type.". The initializer is entirely consistent with those Constraints, so it is within the bounds of what an implementation may accept as an "other form of constant expression". Whereas it wouldn't be valid for an implementation to accept f() as a constant expression (contains a function call), for example. Note also that only violations of Syntax and Constraints require diagnostics (and thus -pedantic doesn't claim to ensure diagnostics for code that's not strictly conforming for some other reason than violating Syntax or Constraints).