[Bug target/101714] New: [POWER] vec_min / vec_max handles NaN incorrectly when evaluated at compile time

[evan--- via Gcc-bugs]

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

            Bug ID: 101714
           Summary: [POWER] vec_min / vec_max handles NaN incorrectly when
                    evaluated at compile time
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: e...@coeus-group.com
  Target Milestone: ---

When a call to vec_min or vec_max with one numeric value and one NaN is
evaluated at compile time, the result is NaN instead of the numeric value.

Here is a quick test case:


#include <stdio.h>
#include <altivec.h>

#if defined(NO_INLINE)
__attribute__((__noinline__))
#endif
__vector float
foo(__vector float a, __vector float b) {
  return vec_min(a, b);
}

int main(void) {
  __vector float a = { 1.0f, __builtin_nanf(""), __builtin_nanf(""), 1.0f };
  __vector float b = { __builtin_nanf(""), 1.0f, __builtin_nanf(""), 1.0f };
  __vector float r = foo(a, b);
  for (int i = 0 ; i < 4 ; i++) {
    printf("%f\n", r[i]);
  }
}


$ gcc -O3 -o minmax minmax.c && ./minmax
nan
nan
nan
1.000000
$ gcc -DNO_INLINE -O3 -o minmax minmax.c && ./minmax
1.000000
1.000000
nan
1.000000
$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.