https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71893
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2016-07-15
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I can reproduce it but get_or_alloc_expr_for must not fail (I see its
implementation can).
Ok, and I see it comes here via
#2 0x000000000102e258 in create_component_ref_by_pieces_1 (
block=<basic_block 0x7ffff68ac680 (3)>, ref=0x1d15800,
operand=0x7fffffffd39c, stmts=0x7fffffffd5e0)
at /space/rguenther/src/svn/trunk/gcc/tree-ssa-pre.c:2590
2590 genop3 = find_or_generate_expression (block, genop3,
stmts);
(gdb) l
2585 genop3 = NULL_TREE;
2586 else
2587 {
2588 genop3 = size_binop (EXACT_DIV_EXPR, genop3,
2589 size_int (TYPE_ALIGN_UNIT
(elmt_type)));
2590 genop3 = find_or_generate_expression (block, genop3,
stmts);
2591 if (!genop3)
2592 return NULL_TREE;
We have
MEM[(character(kind=1)[2][1:D.904] *)_36][0]{lb: 0 sz: (sizetype) _3}
which has bitsizetype sz: but should have sizetype. This is the
thing confusing stuff here I think.
This seems to be introduced during early FRE.
