http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48172
--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-18 11:57:11 UTC --- The patch FAILs FAIL: gcc.dg/vect/pr37539.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr43432.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1 l oops" 2 FAIL: gcc.dg/vect/vect-multitypes-12.c scan-tree-dump-times vect "vectorized 1 l oops" 2 FAIL: gcc.dg/vect/vect-multitypes-16.c scan-tree-dump-times vect "vectorized 1 l oops" 1 on x86_64. I can't see how the alias check is ok for pr37539.c given that we could call ayuv2yuyv_ref with &d[0], &d[4]. Similar for pr43432.c. For vect-multitypes-11.c type-based aliasing should handle the case instead of /space/rguenther/src/svn/trunk/gcc/testsuite/gcc.dg/vect/vect-multitypes-11.c:14: note: versioning for alias required: can't determine dependence between x[i_16] and MEM[(int *)D.3264_7] not sure why this doesn't happen. For -fno-strict-aliasing the runtime test looks bogus as well. vect-multitypes-12.c and vect-multitypes-16.c look similar (but as character types are involved TBAA doesn't help and the vectorization does not appear to be safe). In particular for all tests the segment size we use for the alias tests is not enough for data-refs with differing DR_STEP. It would need to take the number of iterations into account.
