RFR: 8342769: HotSpot Windows/gcc port is broken [v9]

[Julian Waters]

On Mon, 9 Dec 2024 02:03:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> float_sign_mask and friends are only used by Windows ARM64, in the workaround for the Windows CRT bug (I do wish we could get rid of it though!). If looked at closely, the workaround that uses float_sign_mask and friends is only compiled when !X86 && _WIN64, which means Windows ARM64. To simplify:
>> 
>> - All x86 platforms, including x64, use handwritten assembly, so doesn't use float_sign_mask and friends
>> - Windows ARM64 uses float_sign_mask and friends, as it has to use the workaround
>> - All other platforms simply directly call fmod without using float_sign_mask and friends at all, so there is no definition for those platforms
>
> So why does the _M_ARM64 block  not cover all of this code instead of it appearing to be used by other platforms, when it isn't?

I'm not really sure what you mean, if you mean why the _M_ARM64 ifdef doesn't guard the frem and drem implementations in sharedRuntime.cpp here, it's because the Windows/ARM64 implementation with the workaround in it and the implementation for the rest of the platforms (minus x86) are squashed right next to each other. Which implementation is compiled into HotSpot is then determined by the #ifdef _WIN64 check on line 296. If the _M_ARM64 ifdef covered the frem and drem implementation here then the implementation for all non Windows/ARM64 and non x86 platforms would not be defined, and HotSpot wouldn't link at all. Well, that's if I understood you correctly, at least

It might be possible to split the Windows/ARM64 implementation specifically into another file to reduce the confusion, but I feel like that is more trouble than it's worth, and may just cause more issues if not done right. I'd prefer not to do that to avoid all those problems

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875468053