https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98612
--- Comment #2 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Guillaume Piolat from comment #0)
> Created attachment 49926 [details]
> Behaviour with 3 compilers
>
> _mm_comieq_sd has different NaN semantics for different people.
>
> # The Unordered team
> - GCC will return 1 for a comparison that involved NaN.
> - this maps to the underlying instruction
>
> # The Ordered team
> - Intel intrinsics guide says:
>
> RETURN ( a[63:0] == b[63:0] ) ? 1 : 0
>
> which indicates an ordered comparison.
ICC take _mm_{u,}comi{eq,lt,le,gt,ge}_s{s,d} as ordered comparison, and
_mm_{u,}comineq_s{s,d} as unordered comparison, GCC didn't take {Q,}NAN operand
into consideration.
The codes has been in gcc for more than 15 years, and I'm not sure if some
applications are taking advantage of this "bug" in gcc, so do we really need to
"fix" it?
Technically, we can just "refine" as.
modified gcc/config/i386/emmintrin.h
@@ -515,7 +515,7 @@ _mm_cmpunord_sd (__m128d __A, __m128d __B)
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_comieq_sd (__m128d __A, __m128d __B)
{
- return __builtin_ia32_comisdeq ((__v2df)__A, (__v2df)__B);
+ return __A[0] == __B[0];
}
