Bug 101714 - [POWER] vec_min / vec_max handles NaN incorrectly when evaluated at compile time
Summary: [POWER] vec_min / vec_max handles NaN incorrectly when evaluated at compile time
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2021-08-01 13:18 UTC by Evan Nemerson
Modified: 2021-08-02 08:40 UTC (History)
0 users

See Also:
Host:
Target: powerpc
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Evan Nemerson 2021-08-01 13:18:22 UTC
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.