On 6/17/22 09:36, Andrew Haley wrote:
On 6/16/22 19:00, Browser wrote:
> That one I'll chalk up to not-yet-resolved issue with GCC 12. Mainline does
not seem to fail GCC 12
> the same way, but it does fail too.
> sh...@redhat.com:
>> Pleasing the newer compiler version is always something in
>> progress. Meanwhile, as usual, configuring with
>> --disable-warnings-as-errors helps to demote these warnings to just
>> warnings.
This is the Undefined Behaviour bug that I fixed for AArch64 in
8276563, Undefined Behaviour in class Assembler. Compilers get
smarter, and IMO this is an evil hack from decades ago that we should
fix.
The problem is that all instances of type Register exhibit UB in the
form of wild pointer (including null pointer) dereferences. It isn't
very hard to fix: we should make Registers pointers to something
rather than aliases of small integers.
I'd like to apply the same fix to x86, so we never hear of this bug
again. What do you think?
Yes, please. I think I am seeing this now in mainline JDK with GCC 11:
* For target hotspot_variant-server_libjvm_objs_sharedRuntime_x86_32.o:
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp: In
static member function 'static OopMap* RegisterSaver::save_live_registers(MacroAssembler*, int,
int*, bool, bool)':
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:260:48:
error: 'this' pointer is null [-Werror=nonnull]
260 | map->set_callee_saved(STACK_OFFSET(rax_off), rax->as_VMReg());
| ^~~
In file included from
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/share/code/vmreg.inline.hpp:31,
from
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/macroAssembler_x86.hpp:30,
from
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/share/asm/macroAssembler.hpp:31,
from
/home/buildbot/worker/build-jdkX-debian12/build/src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp:26:
--
Thanks,
-Aleksey
