Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop noexcept specifier in defaulted Kokkos::complex default constructor #4399

Merged
merged 3 commits into from
Oct 12, 2021

Conversation

e10harvey
Copy link
Contributor

@e10harvey e10harvey commented Oct 12, 2021

Fixes #4376.

Tested d9187bb via nightly XL build number 51 and 9804013 via build number 52.

@@ -77,7 +77,7 @@ class

//! Default constructor (initializes both real and imaginary parts to zero).
KOKKOS_DEFAULTED_FUNCTION
complex() noexcept = default;
complex() KOKKOS_IMPL_IBM_WORKAROUND_NOEXCEPT_SPEC_CONSTRUCTOR = default;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No I think the right thing to do is just drop the noexcept

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all toolchains?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @dalg24 here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For all toolchains?

Yes. IMO, the noexcept should not have been there in the first place.
@nliber any opinion on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the motivation for dropping noexcept? We have no failures outside the XL toolchains.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The exception specification will be deduced by the compiler https://eel.is/c++draft/except.spec#7
and I can't think of a good reason why we would want to "force" the noexcept

Copy link
Contributor

@nliber nliber Oct 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we don't want to force the noexcept.

noexcept means that if an exception is in flight and it tries to get past that function call, std::terminate will be called. It means that an exception will not escape and not that an exception isn't thrown. In general, this can generate extra code.

As specified above, the defaulted special member functions just get it correct without having to specify it. There are standard library optimizations based on move and swap having the correct noexcept specification; anything else should have additional justification for adding it.

(The standard library adds noexcept to dereferencing smart pointers. The justification at the time was that is was never a pessimization and sometimes a performance improvement, but that claim was made w/o evidence.)

Copy link
Contributor

@nliber nliber Oct 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While these don't necessarily pertain to our code, the current LEWG guidelines on noexcept in the standard library can be found in P0884. These rules are guidelines, but can be overridden as long as there is justification for doing so.

@dalg24 dalg24 changed the title Conditionally select noexcept for IBM builds Drop noexcept specifier in defaulted Kokkos::complex default constructor Oct 12, 2021
@dalg24 dalg24 merged commit 5c52a81 into kokkos:develop Oct 12, 2021
@ajpowelsnl ajpowelsnl added the Blocks Promotion Overview issue for release-blocking bugs label Oct 18, 2021
crtrott pushed a commit to crtrott/kokkos that referenced this pull request Oct 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Blocks Promotion Overview issue for release-blocking bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants