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
