On 2024-04-01 12:05:30 +0100, Alastair McKinstry wrote: > > On 23/03/2024 01:58, Thorsten Glaser wrote: > > Andrey Rakhmatullin dixit: > > > > > OPAL_THREAD_ADD_FETCH64 is defined under #if OPAL_HAVE_ATOMIC_MATH_64 > > > And 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?
Adding another transition on top will just delay the time_t transition even more. So if we can avoid that, I'd prefer to not do this transition now. Unfortunately, uploads such as the one of pmix that no dropped support for 32 bit architectures (#1068211) are not really helpful. Also, #1064810 has no information on test builds with the new mpi-defaults on a 32 bit architecture. So has this transition been tested? Cheers -- Sebastian Ramacher
