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.

Reply via email to