http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450
--- Comment #4 from rguenther at suse dot de <rguenther at suse dot de> 2012-03-05 09:19:12 UTC --- On Mon, 5 Mar 2012, dave.anglin at bell dot net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52450 > > --- Comment #3 from dave.anglin at bell dot net 2012-03-05 00:12:35 UTC --- > On 1-Mar-12, at 10:52 AM, rguenth at gcc dot gnu.org wrote: > > > I think that's expected if your target does not provide a > > movmisalign optab > > for whatever mode is used for > > > > typedef int v4si __attribute__((vector_size(16))); > > > > because of the ever-existing bug with misaligned stores on > > STRICT_ALIGNMENT > > targets. > > > > Consider xfailing it. > > > I'm not convinced that implementing the movmisalign optab would fix > the problem > without a major degradation in performance. Sparc and mips also don't > implement > movmisalign. > > Structs are passed by reference on this target if they are larger than > 64 bits and > the reference is misaligned in this testcase. Ah, but that then hints at a possibly completely different bug. Or at a missed diagnostic from the C frontend that a misaligned object is passed by reference to a function that expects it aligned (the testcase expects that the pass-by-value will make it appear aligned in foo()). Wouldn't we need to perform a copy to aligned storage at the caller site and pass that by reference instead? Note that in this testcase even the callee knows the struct is packed (and thus unaligned), so maybe it's all well-defined and just the middle-end is wrong in the usual way on STRICT_ALIGN targets. [so yes, still XFAIL the testcase but have a frontend/middle-end bug open for this issue] Richard.
