-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_elmhes and test_formats fail on non-x86_64 #1833
Comments
Thanks @opoplawski Looking in the code of 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 |
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 |
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. |
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. |
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. |
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. |
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. |
@opoplawski, do I understand correctly that the tests pass OK on Fedora arm64 builds? |
To go further, one needs at least to know what fails - |
OK, I just compiled current git version on a new M2 machine (OSX) and I have the same issues : On x86 processor, IDL & GDL give (first test) :
But on M2:
Then from my point of view just numerical rounding and the test should be rewritten taking into account EPS |
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. |
I updated Concerning |
The only differences are on unsigned 32 and bits ints and +/-NaN and +INF. I would not say it is an endianess problem. |
see #1949 : some machines (ARM64) do not convert to unsigned ints as on Intel. NaN and INF issues in test_formats come from the fact that these floating-point pseudo-values are converted to unsigned integers (rather than bit fields?) before printing bits (to print we use C and C++ standards). #1949 should have suppressed the float-to-unsigned-int difference of conversion between IA64 and ARM64 (and others, probably). |
Closing with the above explanation, dear Orion you can open a new issue if there is another 'portablity' problem. |
Working on updating the Fedora package to 1.0.5 and getting:
The text was updated successfully, but these errors were encountered: