Test failures for long-double precision on selected architectures.

[ghisvail]

I have uploaded 3.3.2rc3 to Debian, re-enabled long-double testing for all architectures and let the builders do their job. Both powerpc and ppc64el are currently failing.

[ghisvail]

Same with 3.3.2. Logs are available here.

[jenskeiner]

Expected, but I'll try to add a workaround to develop now. Thanks.

Am 01.11.2016 um 16:06 schrieb Ghislain Antony Vaillant notifications@github.com:

Same with 3.3.2. Logs are available here.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ghisvail]

Super. FYI, powerpc has been dropped from the list of major architectures in favor of ppc64el. So if you're investigating an architecture specific issue, you might want to prioritize on the latter.

[jenskeiner]

I reckon that the workaround would be same in both cases, but thanks for the heads up anyway.

Am 03.11.2016 um 10:23 schrieb Ghislain Antony Vaillant notifications@github.com:

Super. FYI, powerpc has been dropped from the list of major architectures in favor of ppc64el. So if you're investigating an architecture specific issue, you might want to prioritize on the latter.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[jenskeiner]

We've added a way of determining the machine epsilon ourselves to safeguard against wrong definition in float.h. The latter seemed to be the cause we failed on ppc architectures. The fix will be included in NFFT 3.4.0. I hope we can test again when we have a release candidate.

[michaelquellmalz]

@ghisvail We have created the release candidate with tag 3.4.0-rc1. Could you run tests again?

[tvolkmer]

Added the help wanted label because I'm unable to reproduce this error on the OpenPOWER@UNICAMP computers. The error has only been observed on debian build machines so far.