testcase 1: int foo(int n) // should not ICE { return ({struct {int x[n];} x; x.x[12] = 1; x;}).x[12]; } internal compiler error: in force_constant_size, at gimplify.c:708 testcase 2: int foo(void) // should not ICE { return sizeof({int n = 20; struct {int x[n];} x; x.x[12] = 1; x;}); } internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:1664 testcase 3: int foo(void) // should not return 0 { int n = 0; return sizeof({n = 10; struct {int x[n];} x; x;}); } returns 0 (actually it's sizeof(int)*original value of n) testcase 4: int foo(void) // should not ICE { return (*({ int n = 20; char (*x)[n][n] = malloc(n * n); (*x)[12][1] = 1; x; }))[12][1]; } same ICE as in #2; note that here the only gccism in ({...}) testcase 5: int foo(void) // should return 1, returns 0 { int n = 0; return (*({ n = 20; char (*x)[n][n] = malloc(n * n); (*x)[12][1] = 1; (*x)[0][1] = 0; x; }))[12][1]; } all writes go to the value-of-malloc + 1
Have fun... A sane approach would be to require the type of ({...}) to make sense on the outside. AFAICS, the root cause of that crap is that ({...}) allows leaking types out of scope where they are defined... In any case, ICE even on violated constraints is Not Nice(tm), especially when those constraints are never stated. Note that earlier versions (at least 4.0.2 and 4.1.1) also break on the same testcases, so it's not a result of recent change - just a dark corner that hadn't been thought through when designing semantics of ({...}). -- Summary: mixing ({...}) with VLA leads to massive breakage Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aviro at redhat dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970