H5LS-tattrreg_be test fails on OpenBSD PowerPC

[seanm]

With current master plus this patch: #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.

[epourmal]

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: #1195<#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 GitHub<#1214>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLFT3NXG7DQMHFMMRGP7IDUNGFIHANCNFSM5IPYLBJQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[seanm]

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?

[epourmal]

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 GitHub<#1214 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADLFT3IGV3HS2OWV2KX3GW3UNGMKDANCNFSM5IPYLBJQ>. Triage notifications on the go with GitHub Mobile for iOS<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[byrnHDF]

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.

[seanm]

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...

[byrnHDF]

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.

[byrnHDF]

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");
}

[seanm]

it does indeed go into the else if (H5Tequal(type, H5T_NATIVE_HBOOL) == TRUE) branch at the end

[seanm]

@byrnHDF friendly ping... what does it tell us that I get into that branch at the end?

[byrnHDF]

@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.

[seanm]

Sorry, I don't quite grok that... has this identified the problem? or the solution?

[byrnHDF]

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.

[gnuoyd]

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: #1214 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[seanm]

CC: @hyoklee