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);