[Bug tree-optimization/92768] [8/9/10 Regression] Maybe a wrong code for vector constants
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Tue Dec 3 13:22:00 GMT 2019
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.
More information about the Gcc-bugs
mailing list