[aarch64-port-dev ] RFR (XS) 8221725: AArch64 build failures after JDK-8221408 (Windows 32bit build build errors/warnings in hotspot)

[Daniel D. Daugherty]

While there have been changes to make various C++11 compilers
happy/happier, I'm not aware of a project to switch to C++11...

However:

   JDK-8208089 JEP 347: Adopt C++14 Language Features in HotSpot
   https://bugs.openjdk.java.net/browse/JDK-8208089

should be interesting...

Dan


On 4/3/19 9:54 AM, Dmitry Samersoff wrote:
> Thomas,
>
> Just curiosity -
>    did hotspot team consider to start using C++11 sometimes?
>
> e.g. (for this case)
>
> enum lock_mask_constants : uintptr_t { ... };
>
> -Dmitry
>
> On 01.04.2019 7:30, Thomas Stüfe wrote:
>> Hi Alexey,
>>
>> Sorry for breaking aarch64.
>>
>> Kim and me had discussions about this particular fix, see original rfr
>> thread for 8221408.
>>
>> A better solution than adding the cast like you did might be to pull the
>> offending enum  value out and make it a uintx constant too. Or, I could
>> revert my change and make it windows only. Or add a dummy value to the enum
>> and cast that to uintptr, to force its size up.
>>
>> I think a good solution would be one that prevents such errors for other
>> enum values and for other platforms as well.
>>
>> Your patch is fine, if you just want to fix your build now.
>>
>> ..thomas
>>
>> On Sun 31. Mar 2019 at 23:36, Aleksey Shipilev <shade at redhat.com> wrote:
>>
>>> Bug:
>>>    https://bugs.openjdk.java.net/browse/JDK-8221725
>>>
>>> Fix:
>>>
>>> diff -r f062188117ad src/hotspot/cpu/aarch64/aarch64.ad
>>> --- a/src/hotspot/cpu/aarch64/aarch64.ad        Sat Mar 30 21:29:37 2019
>>> +0100
>>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad        Sun Mar 31 23:30:41 2019
>>> +0200
>>> @@ -3443,11 +3443,11 @@
>>>       // Check if the owner is self by comparing the value in the
>>>       // markOop of object (disp_hdr) with the stack pointer.
>>>       __ mov(rscratch1, sp);
>>>       __ sub(disp_hdr, disp_hdr, rscratch1);
>>> -    __ mov(tmp, (address) (~(os::vm_page_size()-1) |
>>> markOopDesc::lock_mask_in_place));
>>> +    __ mov(tmp, (address) (~(os::vm_page_size()-1) |
>>> (uintptr_t)markOopDesc::lock_mask_in_place));
>>>       // If condition is true we are cont and hence we can store 0 as the
>>>       // displaced header in the box, which indicates that it is a
>>> recursive lock.
>>>       __ ands(tmp/*==0?*/, disp_hdr, tmp);   // Sets flags for result
>>>
>>> The offending change pulled some enum constants out, which apparently made
>>> enum representation much
>>> smaller. Not sure if putting the constants back does not break Win32 build
>>> again. So, instead, fix
>>> it up in one place that blows up with build warning-as-error. The fix has
>>> some level of ewwness, but
>>> it seems to be the same as what bytecodeInterpreter.cpp is doing. The
>>> alternative is to cast to
>>> uintx, as macroAssembler_arm.cpp is doing.
>>>
>>> Testing: Linux aarch64 fastdebug build, ad-hoc tests
>>>
>>> --
>>> Thanks,
>>> -Aleksey
>>>
>>>
>>>