[Bug c++/55149] capturing VLA in lambda (error in 4.7.2 ICE in 4.8

["daniel.kruegler at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55149

Daniel KrÃgler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel KrÃgler <daniel.kruegler at googlemail dot com> 2012-10-31 21:56:58 UTC ---
I think your example codes involves at least two different issues here. In the
following my data was realized by using gcc 4.8.0 20121014 (experimental) with
the flags

-Wall -std=c++11 -pedantic

First a test case can be constructed that involves attempting to capture the
VLA alone, like this:

//------------------
void test(int n) {
  int r[n];
  [r]() { return r + 0; };
}
//------------------

giving me 

"3|internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2045|"

I expect that code to result in a problem for the compiler, because according
to 5.1.2 p21 captured arrays are really copied element-by-element and *no*
previous array-to-pointer conversion shall proceed. But VLAs are effectively
not prepared to be copied (in all other expressions they would first undergo an
array to pointer conversion).

The second (more complex) problem seems to be related to the fact that this
lambda closure with an VLA capture also attempts to capture an integer (I don't
know why this is a problem), which becomes observable here

//----------------------
template<class T>
void f(T){ }

void test(int n, int m) {
  int r[n];
  f([r, m](){ return r + m; });
}
//----------------------

"|6|internal compiler error: tree check: expected integer_cst, have mult_expr
in walk_subobject_offsets, at cp/class.c:3431|"

The same problem here:

template<class T>
void f(T){ }

void test(int n, int m) {
  int r[n];
  f([=](){ return r + m; });
}

I found that to produce this effect, both a VLA and an integer must be captured
by copy. 

I think it doesn't make sense technically to capture a VLA by copy because that
would require to copy a VLA - this seems something not foreseen for them by the
nature of that type. In this sense your "workaround" really seems necessary to
me and is *not* equivalent to the "#ifdef VLA" branch. This is one of the rare
situations where array-to-pointer conversions does not immediately happen to an
array.