test_elmhes and test_formats fail on non-x86_64 about gdl HOT 14 OPEN

Thanks @opoplawski

Looking in the code of test_elmhes.pro, due to the way the tests are done internally,
I think these 2 failures (test_elmhes & test_formats) are related to issue in formats :(

I have no way to test on my side on a recent Fedora, and I have no problem on Debian, Ubuntu & OSX !

What is the version of compiler do you have ?

thanks

from gdl.

This is with gcc 14.1.1. But it's also failing on EL9 with 11.4.1. You can check recent build logs here: https://koji.fedoraproject.org/koji/packageinfo?packageID=1830

from gdl.

I'm pretty sure formats won't be OK on non 64 bits machines. So some tests based on formatted string comparison won't work either.
The thing is, nobody in the team knows what GDL should produce on 32 bit machines!
I would suggest to avoid doing these tests on 32 bit machines, as they do not mean that GDL does not work.
And wait for an user that reports a specific issue on 32 bit machine.

from gdl.

These are all 64 bit architectures - aarch64, ppc64le, s390x

from gdl.

These are all 64 bit architectures - aarch64, ppc64le, s390x

@opoplawski sorry but your issue refers to "non-x86_64" architectures. My above comment holds: better to remove theses tests from the list of tests in "non-x86_64" architectures building as they are meaningless.

from gdl.

I was just responding to your comment about 32-bits. But if the tests only apply to x86_64 that's fine. Although it would be nice if the tests could deselect themselves on non-x86_64. Anyway, I'm excluding them now.

from gdl.

thanks @opoplawski but I feel there is a misunderstanding: according to internet, s390x is a 32 bit machine when aarch64 is not. Inasmuch as I expect trouble on 32 bit machines, as we have no such machine with a working IDL at our disposal to crosscheck, there should be no problem on a 64 bit little or big endian IEEE 754 architectures. So your report of a test failure is important in this case.

from gdl.

s390x is definitely a 64 bit architecture: https://developer.fedoraproject.org/deployment/secondary_architectures/s390.html. s390 is 31/32 bit hybrid. I'll reopen then I guess. Let me know what other information would be helpful for tracking this down.

from gdl.

@opoplawski, do I understand correctly that the tests pass OK on Fedora arm64 builds?
In #1788, we are introducing Apple Silicon builds to CI, but the PR is blocked by two tests failing: test_byte_conversion.pro and test_bytscl.pro; if that is the case, it then seems to be an Apple compiler issue?

from gdl.

To go further, one needs at least to know what fails -
1595 errors on test_format: I gues every format is wrong. The test procedure creates a file "formats.GDL". @opoplawski could you send it?
For AppleSilicon, I have access to an M1, just need to find the time.

from gdl.

OK, I just compiled current git version on a new M2 machine (OSX) and I have the same issues :
test_elmhes.pro and test_formats.pro (I will look at test_formats later !)

On x86 processor, IDL & GDL give (first test) :

P               DOUBLE    =   -2.8958759e-07
PT              STRING    = '-00.00000029'
ST              STRING    = '101.32080078'
T               FLOAT     =       101.321
GDL> print, b
     0.500000      11.4800      5.50000      5.00000
      6.25000      30.2200      20.7500      14.5000
     0.680000      3.02080      1.28000      1.28000
     0.360000     0.500000      0.00000      0.00000

But on M2:

P               DOUBLE    =        0.0000000
PT              STRING    = '000.00000000'
ST              STRING    = '101.32079315'
T               FLOAT     =       101.321

GDL> print, b
     0.500000      11.4800      5.50000      5.00000
      6.25000      30.2200      20.7500      14.5000
     0.680000      3.02080      1.28000      1.28000
     0.360000     0.500000      0.00000      0.00000

Then from my point of view just numerical rounding and the test should be rewritten taking into account EPS

from gdl.

Certainly. The cumulative rounding errors make our results different between machines, and, most of all, different with IDL that does not use the same algorithms. The difficulty is to fix a safe error margin, as precisions can well drop down to 10-3 for floats.

from gdl.

I updated test_elmhes.pro in Pr #1840 with a numerical tolerance of 1e-5. For me it is close.

Concerning test_formats.pro, from what I see in the outputs, we do have a big/little indian problem ... It is a serious issue. The good news is I have now a permanent access to a M2 OSX machine (very fast feed. But Is have no time now, and I feel not competent on that. But maybe a simple flag could solve most of the problems. I hope @GillesDuvert will have time for that since he previously improved formats ...

from gdl.

The only differences are on unsigned 32 and bits ints and +/-NaN and +INF. I would not say it is an endianess problem.

from gdl.