RFR: 8319570: Change to GCC 13.2.0 for building on Linux at Oracle

[Magnus Ihse Bursie]

On Tue, 7 Nov 2023 23:37:06 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> Oracle is updating the version of GCC for building the JDK on Linux to 13.2.0.
> 
> Apart from the "obvious" changes, I'll add some color to the CompileJvm.gmk changes. In particular, I ran into two different types of new warnings with GCC 13.2.0:
> 
> 1. linux-aarch64-debug + stringop-overflow
> 
> `src/hotspot/os_cpu/linux_aarch64/atomic_linux_aarch64.hpp:203:66: error: 'long unsigned int __atomic_load_8(const volatile void*, int)' writing 8 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]`
> 
> Only reproduces with fastdebug on linux-aarch64. I tried to understand why the warning is generated and how the code could be fixed but eventually had to give up.. I ended up disabling the warning for linux-aarch64-debug specifically but open to feedback and other alternatives.
> 
> 2. linux + zero + dangling-pointer
> 
> 
> `src/hotspot/share/runtime/thread.hpp:579:77: error: storing the address of local variable 'rm' in '*_thr_current.Thread::_current_resource_mark' [-Werror=dangling-pointer=]`
> 
> The linux/zero build generates lots and lots of dangling pointer warnings. As with the first warning I tried to understand why but also gave up in the end. Like the first warning I disabled it instead, for zero builds. Again appreciating feedback/suggestions.

Build changes look fine (barring the And call change).

make/hotspot/lib/CompileJvm.gmk line 92:

> 90: 
> 91: ifeq ($(DEBUG_LEVEL), fastdebug)
> 92:   ifeq ($(call And, $(call isTargetOs, linux) $(call isTargetCpu, aarch64)), true)

The idiomatic way we have expressed this in other places in the JDK build is:
Suggestion:

  ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, aarch64), true+true)

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16550#pullrequestreview-1720350436
PR Review Comment: https://git.openjdk.org/jdk/pull/16550#discussion_r1386616112