Open seanm opened 2 years ago
Yes, this is big endian. We do test IBM PowerPC.
Why you are using master branch? Did you mean develop?
Sent from my iPhone
On Nov 21, 2021, at 6:29 PM, Sean McBride @.***> wrote:
With current master plus this patch: #1195https://github.com/HDFGroup/hdf5/pull/1195
I can build HDF5 and most tests pass. But the H5LS-tattrreg_be test fails:
The output is:
EXPECT=0" "-D" "TEST_REFERENCE=tattrreg_be.ls" "-P" "/home/builder/external/hdf5/config/cmake_ext_mod/runTest.cmake" < -- Require TEST_EXPECT to be defined -- COMMAND: /home/builder/external/hdf5-bin/bin/h5ls-shared -w80;-v;-d;tattrreg.h5 -- COMMAND Result: 0 -- COMMAND Error: -- line = 30 *ACTUAL: Type: native hbool_t **REFER: Type: native unsigned char
-- COMPARE Result: 1 CMake Error at /home/builder/external/hdf5/config/cmake_ext_mod/runTest.cmake:276 (message): Failed: The output of tattrreg_be.out did not match tattrreg_be.ls
Does the be in this test name mean 'big endian'? I imagine you don't test many of those anymore, but this old PowerMac G5 is big endian.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/HDFGroup/hdf5/issues/1214, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADLFT3NXG7DQMHFMMRGP7IDUNGFIHANCNFSM5IPYLBJQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Sorry, indeed, I'm using the develop
branch. Just so used to saying master
when I mean 'newest'. :)
What OS do you test PowerPC with?
According to our RELEASE.txt for 1.12.1 it is
Linux 2.6.32-573.18.1.el6.ppc64
Sent from my iPhone
On Nov 21, 2021, at 7:30 PM, Sean McBride @.***> wrote:
Sorry, indeed, I'm using the develop branch. Just so used to saying master when I mean 'newest'. :)
What OS do you test PowerPC with?
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/HDFGroup/hdf5/issues/1214#issuecomment-974992317, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADLFT3IGV3HS2OWV2KX3GW3UNGMKDANCNFSM5IPYLBJQ. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I wonder if the compiler version is the issue - hbool_t might be different between compiler versions. On our machine os/compiler version it produces unsigned char.
Not sure I understand... According to H5public.h it's always typedef bool hbool_t;
I don't find any typedef unsigned char hbool_t;
, but maybe I'm just not finding it...
We have to look at h5ls print_native_type function there is a H5Tequal if/else block that checks the "hid_t type". else if (H5Tequal(type, H5T_NATIVE_UCHAR) == TRUE) { h5tools_str_append(buffer, "native unsigned char"); }
That function is called by print_type, which is called after getting the type from the dataset with a H5Dget_type call.
BTW, the boolean check is at the bottom of the tree; else if (H5Tequal(type, H5T_NATIVE_HBOOL) == TRUE) { h5tools_str_append(buffer, "native hbool_t"); }
it does indeed go into the else if (H5Tequal(type, H5T_NATIVE_HBOOL) == TRUE)
branch at the end
@byrnHDF friendly ping... what does it tell us that I get into that branch at the end?
@byrnHDF friendly ping... what does it tell us that I get into that branch at the end?
Only that on that machine H5T_NATIVE_HBOOL matches the datatype - native datatypes are machine/os/compiler dependent.
Sorry, I don't quite grok that... has this identified the problem? or the solution?
Not sure - only that there can be differences depending on machine/os/compiler. I might be wrong but I think I have run into NATIVE type differences before. Better is to use STD types.
On Wed, Jan 12, 2022 at 09:16:46AM -0800, Allen Byrne wrote:
Not sure - only that there can be differences depending on machine/os/compiler. I might be wrong but I think I have run into NATIVE type differences before. Better is to use STD types.
I think the test may be flawed. Seems like it should avoid the use of
native types altogether. The h5ls simple output (-S
) seems to avoid
native types.
Nevertheless, looks like something went sideways in print_native_type -> H5Tequal -> H5T_cmp? It may be necessary to step through in the debugger to see why none of the 8-bit-wide, unsigned integer types match the type of Dataset2.
Dave
-- Reply to this email directly or view it on GitHub: https://github.com/HDFGroup/hdf5/issues/1214#issuecomment-1011274329 You are receiving this because you are subscribed to this thread.
Message ID: @.***>
CC: @hyoklee
With current master plus this patch: https://github.com/HDFGroup/hdf5/pull/1195
I can build HDF5 and most tests pass. But the
H5LS-tattrreg_be
test fails:The output is:
Does the
be
in this test name mean 'big endian'? I imagine you don't test many of those anymore, but this old PowerMac G5 is big endian.