> On May 27, 2021, at 3:35 AM, Taylor R Campbell > <[email protected]> wrote: > >> Date: Wed, 26 May 2021 19:46:57 -0700 >> From: Jason Thorpe <[email protected]> >> >> The test program sets up a SIGFPE handler, and the handler make a >> copy of the siginfo, sets a global flag, and returns. The program >> then does "1.0 / 0.0" and prints the result. It checks to ensure >> that the DZE exception is set via fpgetsticky(). It then does "1.0 >> / 0.0" again, and then verifies that the SIGFPE handler was not >> called a second time (because I never cleared DZE with >> fpsetsticky()). > > This strikes me as wrong. > > The status flags (fpgetsticky, fetestexcept) don't determine whether a > floating-point operation `signals an exception' (in the language of > IEEE 754-2019); they only record whether it happened in the past. > > It seems to me that if an operation [ieee754-]signals an exception > that the user has asked (with fpsetmask/feenableexcept) to be trapped, > then it should deliver a [unix-]signal, irrespective of whether some > past operation already [ieee754-]signalled an exception.
I agree. I was describing behavior the alpha port already had. I will write a unit test for this behavior (specifically round DZE), or make sure that there is one that covers it already (there may be … I’m still peeling the onion on the alpha port…) >> The alpha code has, for a very long time, always advanced the PC >> past the faulting instruction on an arithmetic trap[1]. This, in >> essence, makes it behave exactly as if the exception were disabled, >> while still giving the handler a chance to "do something"). >> >> But the x86_64 code appears to return to the same instruction, >> banging its head against the proverbial wall. >> >> It's my belief that the alpha behavior is more desirable. > > I agree. It would be perfectly reasonable to use a SIGFPE handler to, > say, record a history of the instructions (and perhaps stack traces) > that signalled floating-point exceptions, to give more precise > diagnostic information about where they're happening than the status > flags do -- without otherwise interrupting the flow of the program. > > The default exception handling defined in IEEE 754-2019 precisely > defines what the results of the operation should be, so there's no > semantic ambiguity about what the program should observe when it > proceeds on return from the signal handler. Ok, I will write a unit test that verifies this behavior. Thanks! -- thorpej
