JDK-8320212 : Disable GCC stringop-overflow warning for affected files
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2023-11-15
  • Updated: 2024-09-27
  • Resolved: 2023-11-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22
21.0.5Fixed 22 b25Fixed
Related Reports
Relates :  
Relates :  
Description
With the changes in JDK-8319883 GCC 13.2.0 generates stringop-overflow warnings on linux-x64-zero fastdebug. For example:

In file included from src/hotspot/share/runtime/atomic.hpp:859,
                 from src/hotspot/share/oops/oop.hpp:34,
                 from src/hotspot/share/runtime/handles.hpp:29,
                 from src/hotspot/share/classfile/vmClasses.hpp:30,
                 from src/hotspot/share/classfile/javaClasses.hpp:28,
                 from src/hotspot/share/runtime/handshake.cpp:26:
In member function 'T Atomic::PlatformLoad<byte_size>::operator()(const volatile T*) const [with T = long unsigned int; long unsigned int byte_size = 8]',
    inlined from 'T Atomic::LoadImpl<T, PlatformOp, typename std::enable_if<(std::is_integral<_Tp>::value || std::is_pointer<_Tp>::value), void>::type>::operator()(const volatile T*) const [with T = long unsigned int; PlatformOp = Atomic::PlatformLoad<8>]' at src/hotspot/share/runtime/atomic.hpp:513:24,
    inlined from 'static T Atomic::load(const volatile T*) [with T = long unsigned int]' at src/hotspot/share/runtime/atomic.hpp:870:49,
    inlined from 'T Atomic::PlatformOrderedLoad<byte_size, type>::operator()(const volatile T*) const [with T = long unsigned int; long unsigned int byte_size = 8; ScopedFenceType type = X_ACQUIRE]' at src/hotspot/share/runtime/atomic.hpp:878:24,
    inlined from 'T Atomic::LoadImpl<T, PlatformOp, typename std::enable_if<(std::is_integral<_Tp>::value || std::is_pointer<_Tp>::value), void>::type>::operator()(const volatile T*) const [with T = long unsigned int; PlatformOp = Atomic::PlatformOrderedLoad<8, X_ACQUIRE>]' at src/hotspot/share/runtime/atom\
ic.hpp:513:24,
    inlined from 'static T Atomic::load_acquire(const volatile T*) [with T = long unsigned int]' at src/hotspot/share/runtime/atomic.hpp:884:67,
    inlined from 'uintptr_t SafepointMechanism::ThreadData::get_polling_word()' at src/hotspot/share/runtime/safepointMechanism.inline.hpp:48:30,
    inlined from 'static bool SafepointMechanism::local_poll_armed(JavaThread*)' at src/hotspot/share/runtime/safepointMechanism.inline.hpp:52:47,
    inlined from 'static bool SafepointMechanism::should_process(JavaThread*, bool)' at src/hotspot/share/runtime/safepointMechanism.inline.hpp:60:24,
    inlined from 'static void Handshake::execute(HandshakeClosure*, ThreadsListHandle*, JavaThread*)' at src/hotspot/share/runtime/handshake.cpp:404:43:
src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp:147:16: 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=]
  147 |   __atomic_load(const_cast<T*>(src), &dest, __ATOMIC_RELAXED);
      |   ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In static member function 'static void Handshake::execute(HandshakeClosure*, ThreadsListHandle*, JavaThread*)':
cc1plus: note: destination object is likely at address zero
Comments
A pull request was submitted for review. URL: https://git.openjdk.org/jdk21u-dev/pull/797 Date: 2024-06-27 08:39:08 +0000
27-06-2024

[jdk21u-fix-request] Approval Request from Aleksey Shipilëv This batch of fixes improves the warnings handling for newer GCCs. Part of atomic 21u PR, since it contextually depends on other fixes. Risk is low: adds warnings and moves the code around. Was in mainline for months without ill effects.
27-06-2024

The fix for this bug is integrated in jdk-22+25-1955.
18-11-2023

Changeset: a1e7a302 Author: Mikael Vidstedt <mikael@openjdk.org> Date: 2023-11-17 21:37:49 +0000 URL: https://git.openjdk.org/jdk/commit/a1e7a302c8a3d7a1069659653042476b20becabe
17-11-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16702 Date: 2023-11-17 00:31:36 +0000
17-11-2023

<incorrect comment deleted>
16-11-2023

I think I finally figured out what GCC is _actually_ whining about: The way JavaThread::current() is implemented it (looks to GCC like it) can return nullptr, and when that gets used to read the _polling_word it all goes through the atomic template magic and ends up as an argument to __atomic_load. For a nullptr object the region is indeed of size 0. (It doesn't exactly help that the GCC warning complains about the "destination" when, in fact, it's all about the source pointer/data.)
15-11-2023