[geos-devel] 3.9.0beta2

[Paul Ramsey]

> On Dec 4, 2020, at 4:44 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> 
> 
>> On Dec 4, 2020, at 4:16 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>> 
>> 
>> 
>>> On Dec 4, 2020, at 4:08 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>> 
>>> 
>>> 
>>>> On Dec 4, 2020, at 1:10 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
>>>> 
>>>> 
>>>>> On Dec 3, 2020, at 10:18 PM, Sebastiaan Couwenberg <sebastic at 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.
>> 
>> In fact, a debug build passes all tests straight off master, no replacement work on DD required. This perhaps explains my success testing GEOS on ARM earlier.
> 
> Narrowing the situation further: I can do a standard release build using CLANG and it passes all tests. This problem is only associated with GCC and the flags it uses for a release build. Not clear which ones are the problem though, they all look pretty anodyne.

Calling it a night. I cannot figure out which option, if any, in the O2 release build GNU g++ is doing is causing failures. The "obvious" one, -fno-fast-math, makes no difference. Nor does adding -ffloat-store. I wonder if it's possible that this is a g++ bug? The manual seems pretty clear that no options that affect IEEE correctness get flipped until you go to -O3 or -Ofast.

P