Fix BP5 cross-endian support for big-endian architectures (s390x) #4803
Conversation
eisenhauer
force-pushed
the
fix-bp5-cross-endian
branch
4 times, most recently
from
269938b to
ba73f6e
Compare
eisenhauer
force-pushed
the
fix-bp5-cross-endian
branch
from
ba73f6e to
ca8b388
Compare
eisenhauer
force-pushed
the
fix-bp5-cross-endian
branch
2 times, most recently
from
9b3c678 to
3a6c125
Compare
|
This should be ready for review after tests pass... |
|
@vicentebolea This PR is waiting for an infrastructure review, which I think has to be you or Scott as I can't review my own. |
|
Ill have a look later today.
…On Wed, Jan 28, 2026 at 6:58 PM Greg Eisenhauer ***@***.***> wrote:
*eisenhauer* left a comment (ornladios/ADIOS2#4803)
<#4803 (comment)>
@vicentebolea <https://github.com/vicentebolea> This PR is waiting for an
infrastructure review, which I think has to be you or Scott as I can't
review my own.
—
Reply to this email directly, view it on GitHub
<#4803 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHFOFWWHI6PIOLR5FCAYXT4JFELXAVCNFSM6AAAAACRWYMJUGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMJUGU2TQMZVGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
[image: logo shows large letter K with the word Kitware below it]
<http://www.kitware.com>
Vicente Bolea, MSc.
*Senior R&D Engineer*
|
eisenhauer
force-pushed
the
fix-bp5-cross-endian
branch
from
5818383 to
f73ef21
Compare
This commit fixes cross-endian file reading for big-endian architectures (s390x) and removes the ADIOS2_USE_Endian_Reverse CMake option. Cross-endian file interoperability is now always enabled, allowing files written on big-endian systems to be read on little-endian systems and vice versa without any special build configuration. Co-Authored-By: Claude Opus 4.5 <[email protected]>
eisenhauer
force-pushed
the
fix-bp5-cross-endian
branch
from
f73ef21 to
5c5c300
Compare
| outMemStart[DimCount - 1] *= 2; | ||
| if (outMemCount.size() > 0) | ||
| outMemCount[DimCount - 1] *= 2; | ||
| } |
There was a problem hiding this comment.
I do not understand this logic, is it a transformation of little to big endian representation?
There was a problem hiding this comment.
Yes. The deal is that NdCopy (which we call with these inputs) has the byteswapping functionality built into it. It takes the element size as one of its inputs, and as it copies the data it needs from its input to its output it does any byteswapping that's necessary. But this doesn't work quite right with complex types. You don't want to byteswap the whole 16-byte type (for doubles) because that would swap the real and imaginary parts. Instead you want to do each 8-byte half separately. We make that happen here with a little trick. If it's a complex type and we're byteswapping, we halve the element size and double the count in the smallest dimension. That makes everything come out right.
3 participants
This fixes BP5 files written on big-endian architectures (like s390x) to be readable on little-endian architectures (like x86) and vice versa.
Tested with BP5 files written on s390x (big-endian) and read on x86 (little-endian).