Re: One more oddity with gcc and vax floats...

On 6/10/26 15:31, John Klos wrote:
>>>> =C2=A0This is just one more problem with non-IEEE floating point. Si=
nce this
>>>> =C2=A0is a battle that cannot be won maybe I should put the dust of =
the
>>>> =C2=A0"Emulate IEEE floating point" stuff I once worked on.=C2=A0 Mu=
st read up on
>>>> =C2=A0the IEEE 754 standard first though.
>>>
>>> =C2=A0i wouldn't hate this. :-)
>>
>> I'm not convinced. Starting to do all FP math in software will be=20
>> costly, on a machine that is already suffering heavly with performance=
=20
>> issues.
>=20
> Why couldn't hardware floating point do much of the work?

Because if you want IEEE functionality, you need to use IEEE=20
representation, and IEEE semantics on operations when/if they involve=20
Inf or NaN.
>>> =C2=A0it is one of the more annoying, common, problems when trying to
>>> =C2=A0build modern software on vax.
>>
>> True. Sadly, most of the time it isn't really an issue with the actual=
=20
>> software as such, but either a problem with tests, or an expectation=20
>> of Inf and/or specific forms of NaN existing on the machine. Tests are=
=20
>> hard to fix, but most of the time the code that use Inf/NaN will work=20
>> just fine by changing it to something that exists on a VAX.
>=20
> This. Many packages run just fine with NAN set to 0.

Also, VAX do have NaN. But I don't know if you can get the equivalence=20
of non-signalling NaNs.

But I remember building Python many years ago. It worked just fine, but=20
the test suite to verify that it worked correctly always failed.

   Johnny