http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60452
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|tree-optimization |rtl-optimization
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
expand_expr_real_1 for the ARRAY_REF in question does:
/* If we have either an offset, a BLKmode result, or a reference
outside the underlying object, we must force it to memory.
Such a case can occur in Ada if we have unchecked conversion
of an expression from a scalar type to an aggregate type or
for an ARRAY_RANGE_REF whose type is BLKmode, or if we were
passed a partially uninitialized object or a view-conversion
to a larger size. */
must_force_mem = (offset
|| mode1 == BLKmode
|| bitpos + bitsize > GET_MODE_BITSIZE (mode2));
...
/* Otherwise, if this is a constant or the object is not in memory
and need be, put it there. */
else if (CONSTANT_P (op0) || (!MEM_P (op0) && must_force_mem))
{
tree nt = build_qualified_type (TREE_TYPE (tem),
(TYPE_QUALS (TREE_TYPE (tem))
| TYPE_QUAL_CONST));
memloc = assign_temp (nt, 1, 1);
emit_move_insn (memloc, op0);
op0 = memloc;
mem_attrs_from_type = true;
}
op0 is DECL_RTL of the array, (reg/v:DI 85 [ e ]), bitpos is 0x400000, bitsize
is 32, mode2 is DImode.
Not sure if it is safe to set MEM_EXPR (etc. on assign_temp result, if it is,
we could do that. Note that MEM_NOTRAP_P is set on it (I assume it is fine
too, because we should consider it only when not out of bound access).
In any case, as the #c3 testcase shows, even when we do have MEM_EXPR and could
see that it is out of bound, we don't use that info at all.
