<AWT Dev> RFR: 8253375: OSX build fails with Xcode 12.0 (12A7209)

[Matthias Baesken]

On Fri, 25 Sep 2020 02:23:07 GMT, David Holmes <dholmes at openjdk.org> 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