Re: Thoughts about a floating point exception fix

["Maciej W. Rozycki" <macro%linux-mips.org@localhost>]

On Sun, 10 Feb 2019, Greg Stark wrote:

> >  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

 Well, I didn't suggest to disable them for IEEE-754 targets, but for 
`vax-*-*' ones only.  XFAILing them might be a good idea so that they do 
not score as actual failures, however if someone pops up who cares they 
can easily see that and provide alternatives if required.

> 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....

 It's up to whoever implements that in GCC and LD, however the problem is 
not with linking (or dynamic loading), especially as VAX reuses the same 
registers for both integer and FP data, but with format conversion, as 
given the reason for this consideration you surely want the soft-float 
data in the IEEE-754 rather than native-VAX format, don't you?

  Maciej