[Bug c++/99497] New: _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[Bug c++/99497] New: _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[scott_sas_smith at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99497

            Bug ID: 99497
           Summary: _mm_min_ss/_mm_max_ss incorrect results when values
                    known at compile time
           Product: gcc
           Version: 9.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: scott_sas_smith at hotmail dot com
  Target Milestone: ---

_mm_min_ss/_mm_max_ss give unexpected result when values can be determined at
compile time.

Godbolt link: https://godbolt.org/z/7jTbPP
Stack Question:
https://stackoverflow.com/questions/66553905/mm-max-ss-has-different-behavior-between-clang-and-gcc?noredirect=1#comment117656580_66553905

Related Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72867

[Bug target/99497] _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99497

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Simplified:
#include <x86intrin.h>

void
print128 (__m128 var)
{
  float val[4];
  __builtin_memcpy (val, &var, sizeof(val));
  __builtin_printf ("%f %f %f %f \n", val[0], val[1], val[2], val[3]);
}

int
main ()
{
  __m128 a = _mm_set_ss (__builtin_nanf (""));
  __m128 b = _mm_set_ss (2.0f);
  __m128 c = _mm_max_ss (a, b);
  __m128 d = _mm_max_ss (b, a);
  print128 (c);
  print128 (d);
  return 0;
}

The RTL SMAX etc. ops are defined as:
/* Minimum and maximum values of two operands.  We need both signed and
   unsigned forms.  (We cannot use MIN for SMIN because it conflicts
   with a macro of the same name.)   The signed variants should be used
   with floating point.  Further, if both operands are zeros, or if either
   operand is NaN, then it is unspecified which of the two operands is
   returned as the result.  */

DEF_RTL_EXPR(SMIN, "smin", "ee", RTX_COMM_ARITH)
DEF_RTL_EXPR(SMAX, "smax", "ee", RTX_COMM_ARITH)
DEF_RTL_EXPR(UMIN, "umin", "ee", RTX_COMM_ARITH)
DEF_RTL_EXPR(UMAX, "umax", "ee", RTX_COMM_ARITH)

So, if _mm*_{min,max}_ss has the same requirement on what exactly should be
returned when both operands are zero or if either operand is NaN, then we
probably need to use an UNSPEC unless -ffast-math tells us NaNs won't appear or
sign of zero doesn't matter.

[Bug target/99497] _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99497

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And another question is if we without -ffast-math ever create MIN_EXPR/MAX_EXPR
and what exactly are the rules for those, if it is safe to expand those into
SMAX etc., or if those need to use UNSPECs too.

[Bug target/99497] _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99497

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> And another question is if we without -ffast-math ever create
> MIN_EXPR/MAX_EXPR and what exactly are the rules for those, if it is safe to
> expand those into SMAX etc., or if those need to use UNSPECs too.

We don't create them w/o -ffinite-math-only -fno-signed-zeros.  We of course
eventually could, if there's a compare sequence matching the relaxed
requirements.

But MIN/MAX_EXPR should be safe to expand to smin/max always given their
semantics match.

[Bug target/99497] _mm_min_ss/_mm_max_ss incorrect results when values known at compile time

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99497

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Doesn't seem to be a recent regression, even r105000 behaves the same.