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