On Mon, 11 May 2026 07:45:18 GMT, Anton Artemov <[email protected]> wrote:
>> Hi, please consider the following changes:
>>
>> This PR re-enables stringop-overflow warnings.
>>
>> It was assumed that the assert in `Thread::current()`, which calls the
>> `ATTRIBUTE_NORETURN` report function on failure, would be sufficient to
>> inform the GCC compiler that the current thread is always non-null. However,
>> it turns out that the assert is weakened by the `DebuggingContext`:
>>
>> Instead of having
>> `assert(current != nullptr, "Thread::current() called on detached thread");`
>>
>> in fact one gets this:
>> `if ( !(DebuggingContext::is_enabled() || current != null) ) {
>> report_vm_error(...); }`
>>
>> If `DebuggingContext` is enabled then the error will not be triggered
>> regardless of what `current` is. This makes GCC consider the virtually
>> impossible path and emit false positive warnings about atomics.
>>
>> The same problem is found in the Shenandoah code.
>>
>> The fix is to strengthen the assertion by adding a new kind of assert called
>> `invariant_assume()`
>> which removes the assertion completely in product builds, but for debug
>> builds makes it clear for the compiler that the operand cannot be nullptr.
>>
>> With this findings I conclude that it is not a compiler bug.
>>
>> Tested in tiers 1-5 and GHA.
>>
>> Separate builds with Shenandoah done.
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> Anton Artemov has updated the pull request incrementally with one additional
> commit since the last revision:
>
> 8320353: Less bizarre fix.
src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 3:
> 1: /*
> 2: * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
> 3: * Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved.
Suggestion:
* Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31025#discussion_r3217102073
