https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69756
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code,
| |wrong-code
Known to fail| |4.7.4, 6.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, it's that way already during into-SSA.
It seems that we gimplify type sizes and end up using the main()s type size
in the lambda which is uninitialized there:
main()::<lambda()> (const struct __lambda0 * const __closure)
{
sizetype D.2424;
sizetype D.2425;
int[0:D.2357][0:D.2347] * D.2426;
int[0:(sizetype) __closure->__array.max][0:D.2357][0:D.2347] & array
[value-expr: (int[0:(sizetype) __closure->__array.max][0:D.2357][0:D.2347] &)
__closure->__array.ptr];
{
int i4;
int i5;
int i6;
int output;
typedef struct ._0 ._0;
i4 = 1;
i5 = 2;
i6 = 3;
D.2424 = D.2371 /[ex] 4;
D.2371 is defined in main().
This hits at invalid tree (type) sharing between functions and/or invalid
gimplification or un-nesting. Not sure how lambdas are exactly implemented.
