Hi Mark,
On Wed, May 22, 2019 at 02:22:32PM +0100, Mark Rutland wrote:
Currently architectures return inconsistent types for atomic64 ops. Some return long (e..g. powerpc), some return long long (e.g. arc), and some return s64 (e.g. x86).
(only partially related, but probably worth asking:)
While reading the series, I realized that the following expression:
atomic64_t v; ... typeof(v.counter) my_val = atomic64_set(&v, VAL);
is a valid expression on some architectures (in part., on architectures which #define atomic64_set() to WRITE_ONCE()) but is invalid on others. (This is due to the fact that WRITE_ONCE() can be used as an rvalue in the above assignment; TBH, I ignore the reasons for having such rvalue?)
IIUC, similar considerations hold for atomic_set().
The question is whether this is a known/"expected" inconsistency in the implementation of atomic64_set() or if this would also need to be fixed /addressed (say in a different patchset)?
Thanks, Andrea