On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes <[email protected]> wrote:
>> Please review this small patch to enable the OSX build using Xcode 12.0.
>>
>> Thanks,
>> Paul
>
> src/hotspot/share/runtime/sharedRuntime.cpp line 2851:
>
>> 2849: if (buf != NULL) {
>> 2850: CodeBuffer buffer(buf);
>> 2851: short locs_buf[80];
>
> This code is just weird. Why is the locs_buf array not declared to be the
> desired type? If the compiler rejects double
> because it isn't relocInfo* then why does it accept short? And if it accepts
> short will it accept int or long long or
> int64_t? Using int64_t would be a clearer change. Though semantically this
> code is awful. :( Should it be intptr_t ?
Currently we have in the existing code various kind of buffers passed into
initialize_shared_locs that compile nicely
on all supported compilers and on Xcode 12 as well ,see
c1_Compilation.cpp
326 char* locs_buffer = NEW_RESOURCE_ARRAY(char, locs_buffer_size);
327 code->insts()->initialize_shared_locs((relocInfo*)locs_buffer,
sharedRuntime.cpp
2681 CodeBuffer buffer(buf);
2682 short buffer_locs[20];
2683 buffer.insts()->initialize_shared_locs((relocInfo*)buffer_locs,
2684
sizeof(buffer_locs)/sizeof(relocInfo));
So probably using short would be consistent to what we do already in the coding
at another place (looking into
relocInfo it would be probably better to use unsigned short or to typedef
unsigned short in the relocInfo class
and use the typedef).
-------------
PR: https://git.openjdk.java.net/jdk/pull/348
