Re: Thoughts about a floating point exception fix

[Greg Stark <stark%mit.edu@localhost>]

On Sun, 10 Feb 2019 at 13:41, Maciej W. Rozycki <macro%linux-mips.org@localhost> wrote:
>
> On Fri, 8 Feb 2019, Mouse wrote:
>
> > >> How does that differ from just using reserved operands (which the
> > >> hardware already knows how to fault on)?  Would the simulated FP
> > >> include things operationally like infinities or quiet NaNs [...]?
> > > I still don't understand what exactly needs to be fixed in the
> > > software (and if we have to do it in pkgsrc because upstream is
> > > stupid, so be it).
> >
> > I don't understand details myself - I do not have the luxury of playing
> > with VAXen at present - but, based on upthread comments, it looks to me
> > as though python and/or awk have testsuites that rely on infinities and
> > NaNs, possibly as well as details such as you mention, exact ranges and
> > underflow/overflow points and such.
>
>  Well, if it's only test suites that suffer from problems, then I think it
> should be fairly straightforward to fix them by disabling the respective
> tests (or better yet create suitable alternatives) for targets, such as
> the VAX, that have different FP semantics.

I had similar issues trying to get the Postgres test suite to run.
Historically Postgres supports non-IEEE floats but then exposes your
host floating point behaviour when you use floats in SQL.

The problem is that a) we do want tests to ensure we correctly handle
IEEE floating point numbers on IEEE platforms so we definitely want
those tests and b) don't think it would be practical to maintain
alternative output files that only one person with an oddball machine
will be able to generate or check. Especially since it's not just
Inf/NaN behaviour that's affected, the specific number of digits of
precision that operations are done in affects the low order digits in
output. So it's a better tradeoff to just not pass those tests on VAX
than to do anything that will make it harder to maintain tests
elsewhere

It's about to get a lot worse for VAX however. Postgres is about to
adopt the Ryu output algorithms for printing floating point numbers. I
suspect that may be the end of non-IEEE floating point support. There
really isn't much appetite for non-IEEE floating point support.

One alternative I was considering was using IEEE soft floats for the
SQL exposed float data type. But using native floats for internal data
structures. I don't *think* there are any places where we assume
they're the same and probably there shouldn't be. I'm not sure how
easy it would be to convince GCC to compile some files with soft
floats and some with native floats and then link them together
though....


For what it's worth I had to compile Awk without optimizations to get
it to stop working but I assumed that was a GCC code generation bug. I
think the python problem was: I https://bugs.python.org/issue27444

-- 
greg