http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-07 11:36:55 UTC --- On Tue, 6 Dec 2011, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51315 > > --- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-12-06 > 16:41:38 UTC --- > > Note that in the end it's always us transforming > > > > a->b.c > > > > to (effectively) > > > > T *tem = &a->b.c; > > *tem > > > > which expand unfortunately handles differently. So whenever we do that > > we have to either avoid doing that if expand would have a different > > idea about the results alignment (there is currently no way that computes > > just expands idea of an expressions alignment - one piece of a good > > solution would provide that, not only SRA has this "issue"), or, stick > > that information somewhere > > AFAICS that's what the memcpy folder does if STRICT_ALIGNMENT, so the > generated > GIMPLE is perfectly valid. But SRA isn't as cautious as the folder and, in > particular, doesn't compare the alignments of source and destination. In any > case, I don't think that we want to patch outside SRA on the 4.6 branch. The memcpy folder is very conservative, Martin patched SRA to that effect for STRICT_ALIGNMENT targets but that caused a lot of SRA regressions for those targets (and now we have a testcase involving SSE vector moves, thus, on a non-STRICT_ALIGNMENT target). But yes, dumbing down SRA is easy - there is a single function that guards "possibly unaligned" accesses. Richard.