https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2015-01-21 Component|c |tree-optimization Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Well. In a.buf1 + (0 + 4) a.buf1 decays to a (char *) pointer and + 4 just increments it. You can hardly restrict that pointer arithmetic to a sub-object this way. Btw, this is likely caused by 2014-09-05 Richard Biener <rguent...@suse.de> PR middle-end/63148 * fold-const.c (try_move_mult_to_index): Remove. (fold_binary_loc): Do not call it. * tree-data-ref.c (dr_analyze_indices): Strip conversions from the base object again. The docs say @var{type} is an integer constant from 0 to 3. If the least significant bit is clear, objects are whole variables, if it is set, a closest surrounding subobject is considered the object a pointer points to. but I believe we may not actually compute that subobject (or rather the issue, in some cases, is that the wording is ambiguous for nested structs where both &a.b and &a.b.c are at the same address). For the present testcase we can unambiguously compute the closest surrounding subobject. Let me see if I can fix this.