Division by zero [LWN.net]

Division by zero

Posted Jan 4, 2025 13:22 UTC (Sat) by dskoll (subscriber, #1630)
In reply to: Division by zero by pm215
Parent article: Preventing data races with Pony

I get the same SIGFPE on a Raspberry Pi 4 with an aarch64 kernel.

to post comments

Division by zero

Posted Jan 4, 2025 18:09 UTC (Sat) by khim (subscriber, #9252) [Link] (5 responses)

SIGFPE sounds suspiciously like result of floating-point operation. We are talking about integer division here.

Division by zero

Posted Jan 4, 2025 18:12 UTC (Sat) by dskoll (subscriber, #1630) [Link] (2 responses)

Yes, I know. Nevertheless, SIGFPE is the signal that gets raised.

$ cat /tmp/test.c
#include <stdio.h>
int main()
{
    int x = 0;
    int y = 0;
    int z = x/y;
    printf("z = %d\n", z);
    return 0;
}

$ strace /tmp/test
[... bunch of stuff elided ...]
--- SIGFPE {si_signo=SIGFPE, si_code=FPE_INTDIV, si_addr=0x55c090d59153} ---
+++ killed by SIGFPE +++
Floating point exception

Division by zero

Posted Jan 4, 2025 22:56 UTC (Sat) by khim (subscriber, #9252) [Link] (1 responses)

How do you compile that? GCC is smart enough to recognize UB and produce appropriate brk if optimizations are enabled, but that's not related to what CPU is doing. And unoptimized version calls function that can check the divisior.

Try to invoke sdiv directly, then CPU should do what it does. At least for me it produces zero, as CPU manual promised.

Division by zero

Posted Jan 4, 2025 23:18 UTC (Sat) by dskoll (subscriber, #1630) [Link]

I compiled in both cases with make test which simply invoked gcc with no optimization. I checked the assembly output and you are right. On the armhf architecture, it looks like gcc calls into a library function:

        bl      __aeabi_idiv

but on the aarch64 architecture, it calls an assembly instruction:

        sdiv    w0, w1, w0

Division by zero

Posted Jan 4, 2025 19:15 UTC (Sat) by excors (subscriber, #95769) [Link] (1 responses)

glibc says: (https://sourceware.org/glibc/manual/2.40/html_node/Progra...)

> The SIGFPE signal reports a fatal arithmetic error. Although the name is derived from “floating-point exception”, this signal actually covers all arithmetic errors, including division by zero and overflow.

(It notes the integer overflow exception is "impossible in a C program unless you enable overflow trapping in a hardware-specific fashion".)

Division by zero

Posted Jan 4, 2025 22:58 UTC (Sat) by khim (subscriber, #9252) [Link]

I'm surprised not by SIGFPE per see, but by the fact that SDIV suddenly started producing exceptions. Raspberri Pi 4 uses ARM Cortex-A72 which uses ARMv8-A and on ARMv8-A result should be zero, not exception.

If you avoid UB and functions that do manual checks, at least.