On Thu, 20 Jun 2024, Richard Biener wrote: > > > The DIV instructions of MIPS won't be trapped themself if the divisor > > > is zero. The compiler will emit a conditional trap instruct for it. > > > So the signal will be SIGTRAP instead of SIGFPE. > > > > It's an OS kernel bug if you get SIGTRAP for integer division by zero, so > > if a test case fails, it rightfully does. > > MIPS doesn't trap on integer division by zero, instead it's a GCC bug that > we emit a conditional trapping instruction. So I think the fix is fine and > accurate.
Then GCC emits the wrong trap instruction, wherever it comes from and whatever has caused it. The correct ones for integer division by zero (and FWIW overflow; and also the corresponding BREAK variants for MIPS I compatibility) have been designated in the ABI decades ago, documented in MIPS architecture handbooks, including printed ones, and they are supposed to cause the OS kernel to deliver SIGFPE (with the code correctly set) rather than SIGTRAP. It's been like this for 20+ years now, used to work last time I checked (but it may have been a decade ago, possibly when the microMIPS port was added, which sadly needlessly repeated IRIX compatibility breakage here), and suddenly requiring a SIGTRAP here would be a divergence from the ABI and a functional regression. In fact I fixed bugs in this area in the Linux kernel myself, beacuse indeed it used to send SIGTRAP incorrectly, but again it was 20+ years ago. FAOD GAS gets the trap encoding right in output from the DIV, MULO, REM, etc. macros in the MIPS assembly dialect. Maciej
