[Bug c/29970] New: mixing ({...}) with VLA leads to massive breakage

["aviro at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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