http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334
Jan Hubicka <hubicka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2012-11-15
Ever Confirmed|0 |1
--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-11-15
11:42:21 UTC ---
OK, it is not base_address, but base_object
Creating dr for MEM[(real(kind=8)[4] *)&x + 58071104B][0]
analyze_innermost: success.
base_address: &x
offset from base address: 0
constant offset from base address: 58071104
step: 0
aligned to: 128
base_object: MEM[(real(kind=8)[4] *)&x + 58071104B]
Access function 0: 0
I do not see why we need to keep the base object to be offsetted.
While it is first time I see the code, i think it is trying to look for
MEM_REFs and remember the fact that after putting it to 0 the offset may go
across the type boundry, since we changed the type via MEM_REF. For
non-envolving mem-refs this however is not a problem.
I am testing the following that simply removes the constant from MEM_REF
Index: tree-data-ref.c
===================================================================
--- tree-data-ref.c (revision 193503)
+++ tree-data-ref.c (working copy)
@@ -922,6 +922,16 @@ dr_analyze_indices (struct data_referenc
DR_UNCONSTRAINED_BASE (dr) = true;
VEC_safe_push (tree, heap, access_fns, access_fn);
}
+ else
+ {
+ if (!integer_zerop (TREE_OPERAND (ref, 1)))
+ ref = fold_build2_loc (EXPR_LOCATION (ref),
+ MEM_REF, TREE_TYPE (ref),
+ op,
+ build_int_cst (TREE_TYPE (TREE_OPERAND (ref,
+ 1)),
+ 0));
+ }
}
else if (DECL_P (ref))
{
