Andrey Rakhmatullin dixit:OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64And I assume this arch doesn't have 64-bit atomics.No native ones, yes. I *think* either libatomic or libatomic_ops(?) make them available, but very slowly, using a syscall to guarantee atomicity (those systems are normally uniprocessor) on m68k. If possible, avoiding them would be preferrable. (For example, in some cases, like reading a 64-bit timestamp, if the writing direction is known and stable, reading twice then comparing is a possible alternative at least for some architectures (e.g. I know BSD code for sparc does it that way). I guess you’ll have to ask the porters of 32-bit arches with no native 64-bit atomics for details. Though I had thought GCC’s builtin atomics use the aforementioned kernel-based workaround from that library these days?
There is a transition to openmpi-5 / mpi-defaults which is stalled by the t64 transition.
It drops 32-bit support from OpenMPI.
Because of this, I don't think the solution is to port 32-bit atomics for armel/armhf, as it will be removed in a few weeks/months.
While we didn't want the transitions to be done simultaneously, it might be the best answer.
What does the release team think?
bye, //mirabilos
-- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alastair@mckinstry.ie, im: @alastair:mckinstry.ie