http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54781
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-11-20
CC| |jakub at gcc dot gnu.org,
| |ramana at gcc dot gnu.org
Component|middle-end |target
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-20
13:50:08 UTC ---
Looks like a target bug to me, neon_dereference_pointer creates an invalid
MEM_REF (the first operand on it doesn't satisfy the required
is_gimple_mem_ref_addr predicate) and this invalid MEM_REF is then added by
expand_normal into the MEM_EXPR of the MEM, and the aliasing code is then upset
about it.
In particular, the MEM_REF operand is &z[x_5(D)]. The reason why &z[x_5(D)] is
in the CALL_EXPR_ARG of the builtin is expand_call_stmt optimization:
/* TER addresses into arguments of builtin functions so we have a
chance to infer more correct alignment information. See PR39954. */
Best would be if in this case the backend could find out the original argument,
which was a SSA_NAME, and use that as the MEM_REF operand instead, but I'm
afraid we don't have such a way right now. So perhaps the backend could clear
MEM_EXPR
if it is invalid:
case NEON_ARG_MEMORY:
...
if (MEM_EXPR (op[argc]) && TREE_CODE (MEM_EXPR (op[argc])) == MEM_REF
&& !is_gimple_mem_ref_addr (TREE_OPERAND (MEM_EXPR (op[argc]), 0)))
/* Make sure MEM_EXPR created by neon_dereference_pointer isn't
invalid. */
set_mem_expr (op[argc], NULL_RTX);
