Thanks, George, I got it now.
I had missed the fact that opal_atomic_add() is a macro that applies
sizeof() to call the correct atomic function.
So, I believe that Nathan's fixes for the 64-bit atomics support detection
should be the only thing needed.
-Paul
On Tue, May 10, 2016 at 1:50 PM,
The opal_atomic_add function contains all the possible calls to the
underlying atomic functions, based on the size of the data. Thus, if we
detect that 64 bits atomics are available, and if the compiler doesn't
automatically remove the unnecessary code (from the switch case with a
const), then we
George,
I believe that the 64-bit atomics support detection issue that you are
suspecting is already covered by Nathan's PR1659 on master, and will be
PRed/CMRed for v2.x after that is merged.
Regardless of that, however, since the field is declared as "volatile
int32_t" the opal_list code does
Paul,
I think the ref_count should always be manipulated with atomic operations,
otherwise we can't use them for internal, thread-safe, purposes. That being
said the issue at hand seems a little different. The difference in the
generated code between the opal_atomic_add and the OPAL_THREAD_ADD32,
I am currently working with the v2.x branch, rather than tarballs.
While attempting to build on AIX (which is ILP32 by default), I encountered
an unexpected undefined reference to __sync_add_and_fetch_8() from
opal/class/opal_list.h.
I found that when debugging is enabled (as in almost every
