On Tue, 3 Nov 2020 17:40:32 GMT, Coleen Phillimore <cole...@openjdk.org> wrote:
>> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c >> >> This removes the reported warning. >> >> Note that the _LP64 macro was not being propagated to the benchmark native >> libraries on Windows. The comment says that this is due to pack200, but >> since this has been removed [1], it seemed safe to propagate the macro now >> (backed up by testing). >> >> CC'ing hotspot-runtime since I know some people there were looking forward >> to having this fixed. >> >> Testing: tier1-3 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8232022 > > test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c > line 32: > >> 30: #define PTR_TO_JLONG(value) ((jlong) (value)) >> 31: #else >> 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value)) > > Maybe the jlong thisPoint argument comes from a pointer so it's ok. Not > nice, but if you say so, I'll go along. Yes, it's the same pointer that is returned from allocate. It's just stored in a `jlong` on the Java side (this would be a requirement on x64), but it's not expected that the high-order bits are used. Do you have a suggestion for handling this otherwise? ------------- PR: https://git.openjdk.java.net/jdk/pull/1017
