https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117334
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think it's a GCC extension that we accept
const struct s gs = { 3, -4, "abcdef" };
C17 6.7.2.1/21 shows an example where such initialization is invalid as
'struct s' should be treated as if the 'ac' member wouldn't exist.
Given we are not creating a new distinct type at the above initialization (I
think there's bugs about this) the copy then becomes "invalidly valid" as it
is really between distinct types.
It's of course difficult to reject this long-standing language extension.
With -pedantic you'll see that issue:
t.c:7:30: warning: initialization of a flexible array member [-Wpedantic]
7 | const struct s gs = { 3, -4, "abcdef" };
| ^~~~~~~~
t.c:7:30: note: (near initialization for ‘gs.ac’)
and one of the consequences is the "bogus" interpretation of the copy
assignment by the middle-end.
The issue at hand might be fixable at gimplification time, but GENERIC
should be more strictly specificed as what the semantics of the
MODIFY_EXPR with the given LHS/RHS should do (esp. in the absence of
WITH_SIZE_EXPR).
