Jakub Jelinek <ja...@redhat.com> writes: > On Wed, Nov 22, 2017 at 02:51:09PM +0100, Richard Biener wrote: >> On Wed, Nov 22, 2017 at 10:30 AM, Richard Sandiford >> <richard.sandif...@linaro.org> wrote: >> > r254589 was supposed to leave tests unchanged for the default setting >> > of VECTOR_BITS, but I must have got my sums wrong on pr81136.c. >> > Sorry for the breakage. >> > >> > Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu, >> > OK to install? >> >> Ok. > > That will still FAIL e.g. with -march=skylake-avx512 or -march=knl > (at least when not preferring 256 or 128 bit vectors), those would need > ALIGNMENT 64.
Yeah, the real fix for AVX512 is to define VECTOR_BITS. And I'd have thought even AVX2 would need to define it to get clean results on other tests. But the patch that introduced VECTOR_BITS just wasn't supposed to be changing the default behaviour in the way that I'd accidentally done here. Do you know what the vect.exp results are like for 256-bit and 512-bit vectors on x86_64? Like I said in the PR, I was surprised we were the first to hit the need for a macro like VECTOR_BITS. The results for -msve-vector-bits=256 and -msve-vector-bits=512 were really poor without it, since many things were hard-coded to values that made sense for <= 128-bit (or sometimes <= 256-bit) vectors. Thanks, Richard