8374917: [8u] C++ flags get passed to C compiles in the HotSpot build

[gnu-andrew]

In gcc, this has been throwing a warning for a long time:

cc1: warning: command line option '-std=gnu++98' is valid for C++/ObjC++ but not for C

With clang builds, this is instead an error.

2026-01-09T18:17:34.1713580Z error: invalid argument '-std=gnu++98' not allowed with 'C'

This escalates the problem for newer MacOS builds which need the -std flag for the C++ code to compile. It also causes Linux+clang builds to fail.

This fix does the minimum to get C++ flags out of the C code builds (the serviceability agent & jsig):

• NO_DELETE_NULL_POINTER_CHECKS_CFLAG, NO_LIFETIME_DSE_CFLAG and CXXSTD_CXXFLAG
  are moved from EXTRA_CFLAGS to EXTRA_CXXFLAGS. The last of these is essential to fix the problem described above. The others should be safe for the little C code in the HotSpot build; fno-lifetime-dse is a C++ flag anyway and the null pointer checks in question are comparisons of this with NULL from what I can see (again C++ only). Both have been removed in 21u and later, with the required fixes being in the C1 & ADLC code (see JDK-8316893 and JDK-8245051)
• The same for HOST_CFLAGS and HOST_CXXFLAGS used by the ADLC build.
• CFLAGS and LFLAGS in hotspot/make/<platform>/makefiles/adlc.makeare switched to use HOST_CXXFLAGS as this compiles C++ code
• CFLAGS and LFLAGS in hotspot/make/<platform>/makefiles/vm.makeare switched to use EXTRA_CXXFLAGS as this compiles C++ code
• CXXFLAGS are removed from CC_COMPILE in hotspot/make/<platform>/makefiles/rules.make. We leave CXX_COMPILE untouched to reduce risk.

CXXFLAGS is rarely used (though most of the code is C++) while CFLAGS is used for most flags. EXTRA_CXXFLAGS and HOST_CXXFLAGS were unused prior to this change. So the risk of changing these is low, while we leave CFLAGS untouched.

We also move NO_DELETE_NULL_POINTER_CHECKS_CFLAG, NO_LIFETIME_DSE_CFLAG and CXXSTD_CXXFLAG to hotspot-spec.gmk.in from spec.gmk.in. They are now no longer used by the JDK build (which instead adds them to CCXXFLAGS_JDK as can be seen in #740) and this makes it easier to check the values and their usage in a single generated file.

I've built this locally on GNU/Linux with both gcc (8.5.0) and clang (20.1.8). This fix, along with #740 and a few additional warning removal flags, allowed the clang build to complete. I compared the flags in the logs with a previous build from the 8u repository and all desired flags are preserved as before.

Builders may need to adjust their compilation flags if they are relying on --with-extra-cxxflags passing flags to the C code part of the HotSpot build instead of --with-extra-cflags. This is likely worth a release note.

---

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
• JDK-8374917 needs maintainer approval

Issue

• JDK-8374917: [8u] C++ flags get passed to C compiles in the HotSpot build (Bug - P4 - Approved)

Reviewers

• Severin Gehwolf (@jerboaa - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/741/head:pull/741
$ git checkout pull/741

Update a local copy of the PR:
$ git checkout pull/741
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/741/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 741

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/741.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

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

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

8374917: [8u] C++ flags get passed to C compiles in the HotSpot build

Reviewed-by: sgehwolf

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 1 new commit pushed to the master branch:

• 34af1ab: 8074840: Resolve disabled warnings for libjli and libjli_static

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

[mlbridge]

Webrevs

• 00: Full (3e516ce2)

[jerboaa]

Seems OK.

[openjdk]

⚠️ @gnu-andrew This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[gnu-andrew]

Thanks Severin.
/approval request This fix stops C++ compiler flags being passed to the C code parts of the HotSpot build. In particular, -std=gnu++98 is no longer passed to the jsig and saproc parts of the build, which causes a warning on gcc and a fatal error with clang. The potential risk of this change is reduced by only altering the C code parts of the build, with both sets of flags still being passed to the C++ compiler as before. The change was reviewed by Severin Gehwolf.

[openjdk]

@gnu-andrew
8374917: The approval request has been created successfully.

[jerboaa]

/approve yes

[openjdk]

@jerboaa
8374917: The approval request has been approved.

[gnu-andrew]

/integrate

[openjdk]

Going to push as commit 002def2.
Since your change was applied there has been 1 commit pushed to the master branch:

• 34af1ab: 8074840: Resolve disabled warnings for libjli and libjli_static

Your commit was automatically rebased without conflicts.

[openjdk]

@gnu-andrew Pushed as commit 002def2.

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