https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92768
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #5) > Even more reduced: > #include <xmmintrin.h> > > __m128 > foo (__m128 x) > { > int f[4] __attribute__((aligned (16))) > = { 0x00000000, 0x80000000, 0x00000000, 0x80000000 }; > return _mm_xor_ps (x, *(__m128 *) f); > } > > int > main () > { > __m128 a = { -1.0f, -1.0f, -1.0f, -1.0f }; > if (foo (a)[1] != 1.0) > __builtin_abort (); > return 0; > } > > Though, with -fno-signed-zeros, we say that the sign of a zero isn't > significant, but for this testcase it is very much significant. > So, maybe invalid? Well, clearly the testcase simply loads a vector which we do not expect to alter bit-patterns. The issue is that besides the new vector encoder stuff, that native_interpret_expr can end up "normalizing" a FP number as well. Note that various intrinsic docs suggest to use the matching xor_ps variant if the main work is on float vectors while xor_pd when working on integer vectors.