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