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

[Dmitry Samersoff]

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
>>
>>
>>