https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122103
--- Comment #26 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to liu zhenyu from comment #25)
> 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.
Yes, as mentioned above this is intentional. And explicitly mentioned
"However as discussed in PR96373 while we probably shouldn't vectorize for the
cases where we can trap but don't support conditional operation there
doesn't
seem to be a clear consensus on how GCC should handle trapping math.
As such similar to PR96373 I don't stop vectorization if trapping math and
the conditional operation isn't supported."
