8365231: Don't build gtest with /EHsc

[magicus]

According to #26661 (comment), we should not build gtest with /EHsc.

I can honestly say I don't fully understand the consequences of this change, but at least it passes building and testing on Oracle CI. And it does seem to make sense that we build the gtest version of libjvm as close as possible to the real version. For libgtest I just thought it was prudent to keep the flags in sync with how we build libjvm. This might not be the correct decision.

I have not tested how or if this affects the ability for gtest to handle bugs or crashes in the JVM, nor do I really have any idea about any such consequences. This PR is opened more to start a discussion than with the intention of just integrating this.

---

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-8365231: Don't build gtest with /EHsc (Bug - P4)

Reviewers

• Kim Barrett (@kimbarrett - Reviewer)
• Thomas Stuefe (@tstuefe - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 26721

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

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

@magicus 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:

8365231: Don't build gtest with /EHsc

Reviewed-by: kbarrett, stuefe

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 66 new commits pushed to the master branch:

• dbae90c: 8364723: Sort share/interpreter includes
• 059b49b: 8365244: Some test control variables are undocumented in doc/testing.md
• b6d5f49: 8365296: Build failure with Clang due to -Wformat warning after JDK-8364611
• ... and 63 more: https://git.openjdk.org/jdk/compare/10762d408bba9ce0945100847a8674e7eb7fa75e...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.

[openjdk]

@magicus 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 (69ad27ec)

[magicus]

@kimbarrett Any opinions?

[kimbarrett]

How widespread are these warnings? I expect such a warning from jfr/test_networkUtilization.cpp,
but not anywhere else. Could the disable of this warning be narrowed accordingly?

[tstuefe]

googletest uses C++ exceptions:

thomas@starfish:/shared/projects/openjdk/gtest/googletest-1.14.0$ ack 'throw [a-zA-Z]' | wc -l
68

And for C++ exception support we need /EHsc, /EHs or /EHa:
https://learn.microsoft.com/en-us/cpp/build/reference/eh-exception-handling-model?view=msvc-170

Standard C++ exception handling

Full compiler support for the Standard C++ exception handling model that safely unwinds stack objects requires /EHsc (recommended), /EHs, or /EHa.

So I don't think we should remove this compiler option.

[TheShermanTanker]

I did take a brief look at the other Pull Request, but I still don't really understand this fully. Doesn't the gtest framework itself use C++ exceptions (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not used with gcc and clang when compiling gtest. It would be a bit odd if exceptions were disabled for only Windows (More accurately VC) and not any other platform.

[TheShermanTanker]

I don't think this is a good idea. This doesn't fully force disable exceptions like -fno-exceptions does with gcc and clang, it can result in unexpected behaviour that causes hard to track bugs that will be difficult to solve if someone who isn't familiar with HotSpot rules introduces exceptions in gtest code (And perhaps in other cases even when exceptions aren't used too).

[magicus]

So we should not remove exceptions for libgtest. But for the special version of libjvm it still seem to make sense, right? Even if gtest uses exceptions internally in the framework, we should not compile our code differently. Or am I missing something?

[kimbarrett]

googletest uses C++ exceptions:

thomas@starfish:/shared/projects/openjdk/gtest/googletest-1.14.0$ ack 'throw [a-zA-Z]' | wc -l
68

That just says there is source code that could potentially use exceptions, depending on configuration.
It doesn't mean they are used if configured to be disabled. After all, there's GTEST_HAS_EXCEPTIONS.
And spot-checking some of the uses of throw, they are appropriately protected by that macro.

So as long as the macro is set properly...

If not explicitly set, it gets auto-set to 1 for defined(_MSC_VER) && defined(_CPPUNWIND)
with a comment saying the latter is set iff exceptions are enabled. And that seems true according to
https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170
"_CPPUNWIND Defined as 1 if one or more of the /GX (Enable Exception Handling), /clr (Common Language Runtime Compilation), or /EH (Exception Handling Model) compiler options are set. Otherwise, undefined."

[kimbarrett]

I did take a brief look at the other Pull Request, but I still don't really understand this fully. Doesn't the gtest framework itself use C++ exceptions (As Thomas mentioned)? After all, this is likely why -fno-exceptions is not used with gcc and clang when compiling gtest. It would be a bit odd if exceptions were disabled for only Windows (More accurately VC) and not any other platform.

But -fno-exceptions is used for gcc (and probably for clang, though I've not checked). Verified by examination
of ".o.cmdline" files for both libgtest and the HotSpot gtests.

[kimbarrett]

But -fno-exceptions is used for gcc (and probably for clang, though I've not checked). Verified by examination of ".o.cmdline" files for both libgtest and the HotSpot gtests.

Oh, and once again, thank you thank you thank you for the ".o.cmdline" files!

[kimbarrett]

My guess is that MSVC C4530 needs to be disabled when building libgtest even
when we're not enabling exceptions for the same reason that I expected that
warning from our jfr/test_networkUtilization.cpp.

That jfr test includes <vector>, and vector::at throws, and that apparently
isn't protected by anything that knows about exceptions being disabled. (At
least, that's the problem I ran into a while ago.) So even if it's never
called, it still triggers the warning.

googletest also includes <vector> in a bunch of places, so I'd expect the same
issue there. Again, warnings even though that code is never called.

[kimbarrett]

My guess is that MSVC C4530 needs to be disabled when building libgtest even when we're not enabling exceptions for the same reason that I expected that warning from our jfr/test_networkUtilization.cpp.

That jfr test includes <vector>, and vector::at throws, and that apparently isn't protected by anything that knows about exceptions being disabled. (At least, that's the problem I ran into a while ago.) So even if it's never called, it still triggers the warning.

googletest also includes <vector> in a bunch of places, so I'd expect the same issue there. Again, warnings even though that code is never called.

Not <vector>, it's <ostream> or one of those: basic_ostream<...>::operator<<(double) may throw. Didn't see
any warnings from <vector> so that one may have been fixed, but still, it looks like the MS stdlib triggers warnings
when building with exceptions disabled.

So assuming it passes testing, this change seems fine to me.

[kimbarrett]

Assuming no testing issues are encountered, this looks good to me.

[tstuefe]

I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?

What is the motivation for this change? What do we gain by switching the feature off? This switch only applies to the gtest compilation units, right, not to the libjvm? Don't we link googletest and libjvm statically? Are exceptions thrown from header files that are compiled as part of the gtest libjvm?

[TheShermanTanker]

But -fno-exceptions is used for gcc

-fno-exceptions to my knowledge is only set in TOOLCHAIN_CFLAGS_JVM and for adlc compiled for Linux. That must mean gtest uses the same flags that the regular JVM does. I was not aware of that, so that would make my previous statement incorrect.

[magicus]

I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?

As Kim wrote, this seems to be about a bug in the compiler. If you include certain standard headers (<ostream>), the compiler will give this warning, regardless if you use any functions from the header or not, if you compile with exceptions disabled.

Our normal libjvm is compiled with exceptions disabled. It makes sense to run tests on a build that is as close as possible to the real thing, so we should compile libjvm for gtest with exceptions disabled, too.

[tstuefe]

I feel uncomfortable about switching off this warning. I agree with @TheShermanTanker there. Seems to me that if the compiler warns me that I should enable exceptions, I should do that instead of disabling the warning?

As Kim wrote, this seems to be about a bug in the compiler. If you include certain standard headers (<ostream>), the compiler will give this warning, regardless if you use any functions from the header or not, if you compile with exceptions disabled.

Our normal libjvm is compiled with exceptions disabled. It makes sense to run tests on a build that is as close as possible to the real thing, so we should compile libjvm for gtest with exceptions disabled, too.

Okay, so we switch the risk of mismatched tests (since we are compiled with a different setting than the production JVM) with the risk of strange errors should we accidentally trigger C++ exceptions in the googletest framework or in system libraries used by it.

I guess I can see the logic. Okay.