RFR(s): 8221408: Windows 32bit build build errors/warnings in hotspot

[David Holmes]

Hi Thomas,

On 26/03/2019 4:46 pm, Thomas Stüfe wrote:
> Hi David,
> 
> On Tue, Mar 26, 2019 at 7:22 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     Thanks for trying with latest compiler version.
> 
>     On 25/03/2019 11:17 pm, Thomas Stüfe wrote:
>      > Hi all,
>      >
>      > may I please have reviews for the following build fixes for
>     Windows 32bit:
>      >
>      > Issue:https://bugs.openjdk.java.net/browse/JDK-8221408
>      > cr:
>      >
>     http://cr.openjdk.java.net/~stuefe/webrevs/8221408-win32-hotspot-buildfixes/webrev.00/webrev/
> 
>     src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp
> 
>     I see now this change is in #ifndef AMD64 so will only be executed in
>     32-bit.
> 
>     I have to wonder if we can simply appease the compiler by doing this:
> 
>     address os::current_stack_pointer() {
>           int dummy;
>     !   intptr_t addr = (intptr_t) &dummy;
>     !   return (address) addr;
>     }
> 
>     ?
> 
> 
> I find explicitly disabling the warning much clearer to read. Plus, even 
> if we could satisfy the compiler now, this may break with the next 
> compiler update.

I agree with the latter statement, but generally I prefer trying to 
convince the compiler it really has nothing to worry about. :)

>     ---
> 
>        src/hotspot/share/classfile/classFileParser.cpp
> 
>     Ok. As Kim mentioned this had been flagged previously but left alone (I
>     thought perhaps the gcc 8.2 testing ...).
> 
>     ---
> 
>     src/hotspot/share/runtime/vmStructs.hpp
> 
>     Adding the cast is at least consistent with the int32_t casts we add
>     for
>     GENERATE_VM_INT_CONSTANT* but it does make me think we should then also
>     add it to GENERATE_PREPROCESSOR_VM_LONG_CONSTANT_ENTRY.
> 
> 
> Okay, I can do that. Lets see what Kim thinks about the whole thing.

Yeah. I'm still very curious as to why win-64 doesn't include those 
additional enum values.

The error seems to indicate that it thinks the anonymous enum is larger 
than uint64_t - which seems surprising to say the least. :)

Cheers,
David

> Cheers, Thomas
> 
>     Thanks,
>     David
>     -----
> 
> 
>      > Thank you,
>      >
>      > Thomas
>      >
>