8320212: Disable GCC stringop-overflow warning for affected files

[vidmik]

In JDK-8319818 the stringop-overflow warnings were disabled for linux-aarch64 (fastdebug). With the changes in JDK-8319883 additional stringop-overflow warnings are produced with GCC 13.2.0, this time for linux-x64-zero (fastdebug). The warnings are related to GCC thinking JavaThread:current (and Thread::current) may return nullptr where in fact they can't. I tried several ways to convince GCC about this fact but in the end failed.

This change disables the warning for the affected files (only). I'm not in love with that solution but I've run out of ideas at this point. An alternative would be to disable the warning globally, which has its own set of pros and cons.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8320212: Disable GCC stringop-overflow warning for affected files (Bug - P4)

Reviewers

• Magnus Ihse Bursie (@magicus - Reviewer)
• Daniel D. Daugherty (@dcubed-ojdk - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/16702/head:pull/16702
$ git checkout pull/16702

Update a local copy of the PR:
$ git checkout pull/16702
$ git pull https://git.openjdk.org/jdk.git pull/16702/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 16702

View PR using the GUI difftool:
$ git pr show -t 16702

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/16702.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back mikael! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@vidmik The following label will be automatically applied to this pull request:

• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (a2172754)

[magicus]

Looks okay from a build perspective. In the end, I guess some hotspot developers need to weigh in if this is acceptable.

I presume you have tried to analyze what makes the Thread:current access different in these files, so that gcc only complains at these instances?

[openjdk]

@vidmik This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8320212: Disable GCC stringop-overflow warning for affected files

Reviewed-by: ihse, dcubed

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 12 new commits pushed to the master branch:

• 0881f2b: 8318562: Computational test more than 2x slower when AVX instructions are used
• 9b372e2: 8320206: Some intrinsics/stubs missing vzeroupper on x86_64
• b5a7562: 8319985: Delete sun.awt.windows.WToolkit.embedded*() API
• 1fce70b: 8320334: Reflow markdown in testing.md
• 9902d2e: 8315457: Implement JEP 459: String Templates (Second Preview)
• 5522656: 8317834: java/lang/Thread/IsAlive.java timed out
• 9194d2c: 8317357: Update links in building.md to use https rather than http
• 368e4f6: 8315801: [PPC64] JNI code should be more similar to the Panama implementation
• 8ec6b8d: 8319876: Reduce memory consumption of VM_ThreadDump::doit
• bbf52e0: 8319897: Move StackWatermark handling out of LockStack::contains
• ... and 2 more: https://git.openjdk.org/jdk/compare/1588dd934ce4e00a060e329b80f721d894559597...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[vidmik]

Looks okay from a build perspective. In the end, I guess some hotspot developers need to weigh in if this is acceptable.

I presume you have tried to analyze what makes the Thread:current access different in these files, so that gcc only complains at these instances?

Indeed, I spent quite a lot of time trying to understand what makes these specific files (cases/places) special but in the end had to give up. If there is a pattern I can't spot it.

[dcubed-ojdk]

Thumbs up.

Since we're seeing this failure in every Tier5 build-ID, I think we have
to do something to quiet the noise here.

[vidmik]

Thank you for the reviews.

/integrate

[openjdk]

Going to push as commit a1e7a30.
Since your change was applied there have been 12 commits pushed to the master branch:

• 0881f2b: 8318562: Computational test more than 2x slower when AVX instructions are used
• 9b372e2: 8320206: Some intrinsics/stubs missing vzeroupper on x86_64
• b5a7562: 8319985: Delete sun.awt.windows.WToolkit.embedded*() API
• 1fce70b: 8320334: Reflow markdown in testing.md
• 9902d2e: 8315457: Implement JEP 459: String Templates (Second Preview)
• 5522656: 8317834: java/lang/Thread/IsAlive.java timed out
• 9194d2c: 8317357: Update links in building.md to use https rather than http
• 368e4f6: 8315801: [PPC64] JNI code should be more similar to the Panama implementation
• 8ec6b8d: 8319876: Reduce memory consumption of VM_ThreadDump::doit
• bbf52e0: 8319897: Move StackWatermark handling out of LockStack::contains
• ... and 2 more: https://git.openjdk.org/jdk/compare/1588dd934ce4e00a060e329b80f721d894559597...master

Your commit was automatically rebased without conflicts.

[openjdk]

@vidmik Pushed as commit a1e7a30.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.