Clang 19 regression: SIGFPE on -O2

[roe85]

I tried compiling our codebase and I get SIGFPE in an innocent looking function.
I've added noinline, to isolate it further. When called deep in the call tree it crashes with SIGFPE (which should be impossible with the given datatypes)
If I call it in an isolated unit-test with the very same parameters (3,0, 200) it works as expected

[[clang::noinline]]
bool checkIfObjTooBig(uint size_radial, uint size_azimuthal, uint max)
{
    return (size_azimuthal > sqrt(2) * max ||
            size_radial > sqrt(2) * max);
}

The generated Assembly with the supposed crash location.

mov    %esi,%eax
cvtsi2sd %rax,%xmm0
mov    %edx,%eax
cvtsi2sd %rax,%xmm1
mulsd  0x2eb12(%rip),%xmm1        # 0x57bfb8
mov    %edi,%eax
cvtsi2sd %rax,%xmm2
movapd %xmm1,%xmm3
cmpltpd %xmm2,%xmm3       #<- Supposedly SIGFPE happens here
cmpltpd %xmm0,%xmm1
orpd   %xmm3,%xmm1
movd   %xmm1,%eax
and    $0x1,%al
retq

Command line parameters:

-D_REENTRANT -m64 -march=x86-64 -pipe -fno-strict-aliasing  -O2 -g -DNDEBUG -std=c++14 

Could it be that some (parts of) registers are polluted and not really cleared beforehand?

[llvmbot]

@llvm/issue-subscribers-backend-x86

Author: Richard (roe85)

I tried compiling our codebase and I get SIGFPE in an innocent looking function. I've added `noinline`, to isolate it further. When called deep in the call tree it crashes with SIGFPE (which should be impossible with the given datatypes) If I call it in an isolated unit-test with the very same parameters `(3,0, 200)` it works as expected

[[clang::noinline]]
bool checkIfObjTooBig(uint size_radial, uint size_azimuthal, uint max)
{
    return (size_azimuthal > sqrt(2) * max ||
            size_radial > sqrt(2) * max);
}

The generated Assembly with the supposed crash location.

mov    %esi,%eax
cvtsi2sd %rax,%xmm0
mov    %edx,%eax
cvtsi2sd %rax,%xmm1
mulsd  0x2eb12(%rip),%xmm1        # 0x57bfb8
mov    %edi,%eax
cvtsi2sd %rax,%xmm2
movapd %xmm1,%xmm3
cmpltpd %xmm2,%xmm3       #<- Supposedly SIGFPE happens here
cmpltpd %xmm0,%xmm1
orpd   %xmm3,%xmm1
movd   %xmm1,%eax
and    $0x1,%al
retq

Command line parameters:

-D_REENTRANT -m64 -march=x86-64 -pipe -fno-strict-aliasing  -O2 -g -DNDEBUG -std=c++14 

Could it be that some (parts of) registers are polluted and not really cleared beforehand?

[RKSimon]

I'd expect cmpltsd not cmpltpd

[RKSimon]

convertIntLogicToFPLogic is doing some unnecessary vectorization - not sure why its only regressing now

[efriedma-quic]

If you're going to enable floating-point traps, you need to pass -ftrapping-math or equivalent, to disable optimization that might trigger a spurious floating-point exception. By default, LLVM will speculate operations that trigger an exception.

(In this particular case, it looks like the compiler can avoid the spurious FP exception without any performance cost, but we don't make any promises.)

[AZero13]

If you're going to enable floating-point traps, you need to pass -ftrapping-math or equivalent, to disable optimization that might trigger a spurious floating-point exception. By default, LLVM will speculate operations that trigger an exception.

(In this particular case, it looks like the compiler can avoid the spurious FP exception without any performance cost, but we don't make any promises.)

well, yes, because it was comparing random trash in the upper half

and that random trash might've been a NaN

Thanks for fixing this!