Re: [PATCH v1 5/7] fpu/softfloat: avoid undefined behaviour when normalising empty sigs

[Peter Maydell]

On Fri, 27 Mar 2020 at 22:27, Richard Henderson
<address@hidden> wrote:
> I wonder if I have the energy to petition the committee to drop, for C202? all
> of the "undefined" nonsense that only applies to sign-magnitute and
> ones-compliment computers, which haven't been seen since the 70's...

There was certainly a proposal to do that (I think from a Google
engineer) for C++, I forget whether the equivalent C change has
also been proposed.

> > That said, is it valid for this function to be called with a zero
> > aSig value ? I think all these normalizeFloat*Subnormal() functions
> > assume non-zero sig input, and the only callsite where it's not clearly
> > obvious that this is obvious that the sig input is non-zero is the call to
> > normalizeFloatx80Subnormal() from addFloatx80Sigs(). So perhaps we
> > just need to check and fix that callsite ??
>
> You're right -- addFloatx80Sigs is the only use out of 26 that doesn't have a
> preceding check for 0.

Mmm. My vote is for fixing addFloatx80Sigs -- now we just need
to figure out what the desired behaviour is.

thanks
-- PMM