RFR: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid)
Kim Barrett
kbarrett at openjdk.java.net
Sun Oct 4 03:04:37 UTC 2020
On Sun, 4 Oct 2020 00:11:35 GMT, Jie Fu <jiefu at openjdk.org> wrote:
>> Apparently I misremembered. The platform-independent layer isn't doing that canonicalization of enum types to
>> associated integral types. But I think it should be in some places.
>
> Thanks @kimbarrett for your review.
> I'll think it more after my holiday.
What version of clang?
gcc (at least recent versions) allows enum types (both scoped and unscoped) for both the __sync_xxx functions and for
the __atomic_xxx functions. (The documentation for both say the type can be an integral scalar or pointer type. Enums
are not integral types.)
So this seems to be a clang incompatibility with gcc, which may be a clang bug.
The __sync_xxx functions have been legacy since gcc4.7, having been superseded by the __atomic_xxx functions. Could
zero be updated here? Would that help? If clang is incompatible with gcc for the __sync_xxx functions, it might also
be incompatible for the __atomic_xxx functions.
BTW, the memory ordering by the zero implementation of Atomic::xchg in terms of __sync_lock_test_and_set looks wrong to
me. I think the fence() is on the wrong side of the __sync_xxx operation.
-------------
PR: https://git.openjdk.java.net/jdk/pull/496
More information about the hotspot-runtime-dev
mailing list