Re: Expected behavior when returning from a SIGFPE handler

> On May 27, 2021, at 6:17 AM, Jason Thorpe wrote: > >> >> On May 27, 2021, at 3:35 AM, Taylor R Campbell >> wrote: >> >>> Date: Wed, 26 May 2021 19:46:57 -0700 >>> From: Jason Thorpe >>> >>> The test program sets up a SIGFPE handler, and the handler make a >>> copy of the siginfo, sets

Re: Expected behavior when returning from a SIGFPE handler

> On May 27, 2021, at 6:29 AM, Jason Thorpe wrote: > > >> On May 27, 2021, at 3:35 AM, Taylor R Campbell >> wrote: >> >> 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

Re: Expected behavior when returning from a SIGFPE handler

>> In some cases, you want to re-execute the instruction. A simple >> example is "FPU disabled" on architectures that have such a notion, >> eg for lazy FPU switching. > Weâ??re not talking about lazy FPU switching hereâ?? weâ??re talking about p$ (Or timing. Yes.) A better example might be

Re: Expected behavior when returning from a SIGFPE handler

> On May 27, 2021, at 3:35 AM, Taylor R Campbell > wrote: > > 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

Re: Expected behavior when returning from a SIGFPE handler

> On May 26, 2021, at 8:14 PM, Mouse wrote: > >> But the x86_64 code appears to return to the same instruction, banging its h$ > >> It's my belief that the alpha behavior is more desirable. > >> Please, discuss. > > I could argue that either way. > > In some cases, you want to re-execute

Re: Expected behavior when returning from a SIGFPE handler

> On May 27, 2021, at 3:35 AM, Taylor R Campbell > wrote: > >> Date: Wed, 26 May 2021 19:46:57 -0700 >> From: Jason Thorpe >> >> 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"

Re: Expected behavior when returning from a SIGFPE handler

> Date: Wed, 26 May 2021 19:46:57 -0700 > From: Jason Thorpe > > 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

Re: Expected behavior when returning from a SIGFPE handler

> But the x86_64 code appears to return to the same instruction, banging its h$ > It's my belief that the alpha behavior is more desirable. > Please, discuss. I could argue that either way. In some cases, you want to re-execute the instruction. A simple example is "FPU disabled" on

Re: Expected behavior when returning from a SIGFPE handler

On Wed, 26 May 2021, Jason Thorpe wrote: ... 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

Expected behavior when returning from a SIGFPE handler

I've been working on fixing some test case failures on the Alpha port, and I'm elbow-deep in FP-land right now. The Alpha has a somewhat complicated FP story because it has architecture-mandated software completion for essentially anything outside the happy path in hardware, and to support