Created attachment 42388 [details] C program that demonstrates the bug I am running on a 32-bit Ubuntu system. The attached file, fa4.c, shows a problem with the gcc extension which allows static initialization of flexible array members. The problem is in main, with the declaration and initialization of second: s second = first; The compiler isn't allocating space for the flexible array member in second, which makes sense. However, it is copying *all* of first into second, including the space that was allocated for the flexible array member. The result is that it writes past the end of second, and continues writing into the array v. When v is printed, instead of printing <xxxxxxxx>, it instead prints the tail of the string that was copied from first, which comes out as <defgh>. The same behavior is seen if the declaration of and assignment to s are split into: s second; second = first; I believe the assignment should only copy sizeof(s) bytes, rather than including the storage allocated for the flexible array member. Note that if the declaration and static initialization of first is moved to a separate file, the problem disappears, and the structure copy behaves as it should. But when gcc sees the true allocated size of first, it copies too much in the assignment. It should always copy the same amount regardless of where first is defined.
Confirmed. I think the issue is that we make the new type created by constructing the object compatible (or the same) as the second. Then we get to invalid GIMPLE being simply second = first; which ends up using expr_size from the source. Iff the C FE wants to support this kind of assignments (not sure if it really should!) then it needs to tack appropriate WITH_SIZE_EXPRs on the decls.
Both the C and C++ front-end now produce the wrong code.