> On Dec 4, 2020, at 1:10 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote:
>
>
>> On Dec 3, 2020, at 10:18 PM, Sebastiaan Couwenberg <sebas...@xs4all.nl>
>> wrote:
>>
>> On 12/3/20 12:17 AM, Paul Ramsey wrote:
>>> without any further ado, here's a beta2 release for your testing pleasure
>>
>> testrunner fails on arm64, ppc64el, powerpc, ppc64, riscv64:
>
> Have we ever passed? Perhaps I made a big mistake removing ttmath.
>
> Anyways, here's what I've learned today, testing on an AWS ARM64 server.
>
> * Still no obvious reason why these platforms shouldn't just work, if they
> implement IEEE conforming operations on double.
> * There's something called FLT_EVAL_METHOD in <cfloat> which might indicate
> non-IEEE handling of double, but... my test server insists it is
> FLT_EVAL_METHOD == 0 "evaluate just to the range and precision of the type".
>
> Wondering if there was a brutal hack-around, and noting that "long double" is
> increasingly a "thing", I took our DD class, and hacked out all the smarts
> and substituted long double implementations.
>
> https://github.com/pramsey/geos/tree/dd-arm
>
> Interestingly, this implementation passes all the geos::math::DD tests! The
> ARM64 long double appears to have a full 128bit implementation. Running the
> same thing on Intel x64 fails a number of tests. This is probably because the
> long double implementation on x64 has only 80 bits (according to the
> internet).
>
> Does all this test passing mean that a direct use of long double will work on
> platforms that support it? Apparently not. The ARM build still fails on quite
> a few tests of varying sorts, just not on the DD tests.
>
> 90 - unit-capi-GEOSVoronoiDiagram (Failed)
> 140 -unit-linearref-LengthIndexedLine (Failed)
> 208 - general-TestCentroid (Failed)
> 260 - issue-issue-geos-275 (Failed)
> 267 - issue-issue-geos-398 (Failed)
> 349 - robust-TestOverlay-pg-list (Failed)
>
> Where does this leave us? With a long research project on ARM64 to track down
> why these tests fail and/or why the DD implementation fails.
Since this was a finite set of test failures and I was wondering if these
failures were "real" or "tiny", I started going through them and the Voronoi
failures seemed to fall into the "tiny" category. There was/is clearly a double
precision equality test in the code that is returning true on one platform and
false on another, because the answers are very very similar.
When I moved onto unit-linearref-LengthIndexedLine test, there wasn't any good
printed debugging, so I broke out the debugger, and I had to rebuild in Debug
mode. Guess what:
100% tests passed, 0 tests failed out of 364
Yep, with the hardware long double for precision and in debug mode every test
passes. So the problems on ARM64 are even *more* awful to figure out. Something
about the optimized release build is different enough to matter.
P.
> Should we still release? I think so. While ARM and other niche platforms are
> coming down the pike, it doesn't make sense to delay. GEOS isn't "broken" on
> those platforms so much as "not perfect".
>
> P.
>
>
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
