Re: Expected behavior when returning from a SIGFPE handler

[Jason Thorpe <thorpej%me.com@localhost>]

> On May 27, 2021, at 6:29 AM, Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
> 
>> On May 27, 2021, at 3:35 AM, Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost> 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 signal handler.
> 
> Hm, I guess this means that I really need to do software-completion for DZE faults, as well, even if SWC was not explicitly requested for it (we already do that for INV faults to handle QNaNs).  Otherwise, I’m going to be stuck with UNPREDICTABLE as the result, and that’s not great.

…and while we’re at it…

The fenv(3) man suggests that if you have a SIGFPE handler set up in your program with exceptions enabled, and you do a:

	feholdexcept(&env);
	/* do stuff that might raise an exception. */
	feupdateenv(&env);

…that the feupdateenv() call would result in the SIGFPE being delivered to the handler.

Not sure if we have unit tests for that stuff at the moment, but I’m pretty sure the alpha will not do that correctly as it stands (the fenv implementation for alpha appears to have been lifted from a FreeBSD implementation, and it interacts with the FPCR directly, rather than the architecturally mandated FP_C virtual register).

-- thorpej