`H5LS-tattrreg_be` test fails on OpenBSD PowerPC

[seanm]

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:

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

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

[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: https://github.com/HDFGroup/hdf5/issues/1214#issuecomment-1011274329 You are receiving this because you are subscribed to this thread.

Message ID: @.***>

[seanm]

CC: @hyoklee