8299580: RISC-V: fail to build with GCC 12 due to stringop-overflow warning

[RealFYang]

Release fail to build with GCC-12 due to warnings been treated as errors. But the mentioned HotSpot code looks fine, so this looks to me like a GCC-12 suprious warning. This issue does not menifest on other platforms because they are using inline assembly code instead of calling GCC builtins like __atomic_add_fetch to implement class atomic.

Currently, class atomic is only partially implemented with inline assembly code on RISC-V. Instead of disabling the stringop-overflow warning when building HotSpot, I would prefer reimplementing other functions of class atomic using inline assembly code. That way has the extra benefit of providing us fine-grained control on code generation for these atomics. This is the first version which maps to the original implementation with GCC builtins. I will further improve this part distinguishing different memory ordering requirements.

Testing:

• release and fastdebug build fine with both GCC-11 and GCC-12.
• run tier1-3 tests on HiFive Unmatched.
• run non-trivial benchmark workloads like: renaissance, specjvm2008, specjbb2015, etc.

---

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

Integration blockers

 ⚠️ Too few reviewers with at least role reviewer found (have 0, need at least 1) (failed with the updated jcheck configuration)
 ⚠️ Whitespace errors (failed with the updated jcheck configuration)

Issue

• JDK-8299580: RISC-V: fail to build with GCC 12 due to stringop-overflow warning (Bug - P4)

Reviewers

• Feilong Jiang (@feilongjiang - Author)
• Yadong Wang (@yadongw - Author)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11858

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back fyang! 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]

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

• hotspot-runtime

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 (cf9ca0c0)

[feilongjiang]

Looks good.

[kimbarrett]

A similar problem has shown up on linux-aarch64 - https://bugs.openjdk.org/browse/JDK-8294031. I've linked
the two bugs.

It's very interesting that something like this is appearing on multiple platforms. I've been looking at JDK-8294031
on the assumption that it was aarch64-specific. And it sure does look like a gcc bug.

[RealFYang]

A similar problem has shown up on linux-aarch64 - https://bugs.openjdk.org/browse/JDK-8294031. I've linked the two bugs.

It's very interesting that something like this is appearing on multiple platforms. I've been looking at JDK-8294031 on the assumption that it was aarch64-specific. And it sure does look like a gcc bug.

Note that there might be some subtle difference here. I see this issue only triggers when we implement PlatformAdd with builtin __atomic_add_fetch on RISC-V with GCC-12. It does not trigger when we use __atomic_load for PlatformOrderedLoad. So I am not touching PlatformOrderedLoad in this PR.

[yadongw]

lgtm

[kimbarrett]

A similar problem has shown up on linux-aarch64 - https://bugs.openjdk.org/browse/JDK-8294031. I've linked the two bugs.
It's very interesting that something like this is appearing on multiple platforms. I've been looking at JDK-8294031 on the assumption that it was aarch64-specific. And it sure does look like a gcc bug.

Note that there might be some subtle difference here. I see this issue only triggers when we implement PlatformAdd with builtin __atomic_add_fetch on RISC-V with GCC-12. It does not trigger when we use __atomic_load for PlatformOrderedLoad. So I am not touching PlatformOrderedLoad in this PR.

I think it's the same problem, but perhaps with some platform-specific bits. This is being discussed internally to
Oracle right now. I suggest not making this change just yet. It's unclear that such workarounds will really address
the fundamental problem; they might provide a stop gap for a given version of gcc.

[RealFYang]

A similar problem has shown up on linux-aarch64 - https://bugs.openjdk.org/browse/JDK-8294031. I've linked the two bugs.
It's very interesting that something like this is appearing on multiple platforms. I've been looking at JDK-8294031 on the assumption that it was aarch64-specific. And it sure does look like a gcc bug.

Note that there might be some subtle difference here. I see this issue only triggers when we implement PlatformAdd with builtin __atomic_add_fetch on RISC-V with GCC-12. It does not trigger when we use __atomic_load for PlatformOrderedLoad. So I am not touching PlatformOrderedLoad in this PR.

I think it's the same problem, but perhaps with some platform-specific bits. This is being discussed internally to Oracle right now. I suggest not making this change just yet. It's unclear that such workarounds will really address the fundamental problem; they might provide a stop gap for a given version of gcc.

Hi, I am happy to know that this issue is under discussion somewhere for a better solution. Since this only triggers for latest GCC-12 on linux-riscv64 and is not blocking us for now, I can hold on for a while.

[bridgekeeper]

@RealFYang This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[openjdk]

@RealFYang this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout JDK-8299580
git fetch https://git.openjdk.org/jdk master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[bridgekeeper]

@RealFYang This pull request has been inactive for more than 8 weeks and will be automatically closed if another 8 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@RealFYang This pull request has been inactive for more than 16 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.