https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122103
liu zhenyu <lzy20000419 at outlook dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |lzy20000419 at outlook dot com
--- Comment #25 from liu zhenyu <lzy20000419 at outlook dot com> ---
The builtin case in gimple_could_trap_p_1 checks FLOAT_TYPE_P of the call's
return type.
FP builtins with an integer result (lrint, llrint, and probably the
lround/ifloor family
where they are vectorised) can still raise FE_INVALID, and they are still made
unconditional by if-conversion. On x86-64 with AVX-512 (trunk, 15.2 and 14.2
all give the
same code):
```c
#include <fenv.h>
#include <stdio.h>
long out[64];
double in[64];
int a[64]; /* all zero: lrint is never called */
__attribute__((noipa)) void f (int n)
{
for (int i = 0; i < n; i++)
if (a[i])
out[i] = __builtin_lrint (in[i]);
}
int main (void)
{
for (int i = 0; i < 64; i++) in[i] = __builtin_nan ("");
feclearexcept (FE_ALL_EXCEPT);
f (64);
printf ("%d\n", fetestexcept (FE_INVALID) != 0); /* expect 0 */
}
```
gcc -O3 -fno-math-errno -march=x86-64-v4 prints 1 (-O0 prints 0). Only the
store is
masked; the conversion runs on every lane:
```
vpcmpd $4, %zmm0, %zmm2, %k1
vcvtpd2qq in(%rip), %zmm2
vmovdqa64 %zmm1, out+64(%rip){%k1}
```
-fno-tree-loop-if-convert fixes it. Perhaps the check should look at the
argument types
(any FLOAT_TYPE_P argument) as well as the return type.
Disclaimer: This test case was generated by a fuzzer, and the report was
written with LLM assistance.
