-
Notifications
You must be signed in to change notification settings - Fork 142
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
Minimum c++ std to c++17 #3348
Minimum c++ std to c++17 #3348
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR was not made clean.
CMakeLists.txt
Outdated
@@ -410,7 +410,7 @@ include(CMake/Testlibstdc++.cmake) | |||
if(QMC_CXX_STANDARD GREATER_EQUAL 17) | |||
include(CMake/TestCxx17Library.cmake) | |||
else() | |||
include(CMake/TestCxx14Library.cmake) | |||
message(FATAL_ERROR "QMCPACK requires compiler support of c++17 or greater.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function is not responsible for requesting C++17. No change here. If C++14 is needed, it should be allowed. That is why the top level only issues a warning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The point is to stop writing workaround code in c++14 and use the simpler semantics of c++17. So it should be a fatal error to request less than 17 for the standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we still want to give a warning for higher standard numbers like we have in the past.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets make this even easier. Change the top-level CMakeLists.txt warning message to an error. We can then remove the 14 check in Testliststdc++.cmake
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't live in a perfect world... The warning is clear, it is on your own. But we should not add even more hurdles when sb is struggling with C++14 need.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NVHPC since 20.7 has supported c++17
I think that was the first release
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I don't know how to really support NVHPC without cmake CUDA as a language
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NVHPC should work without CUDA. Imagine you hit a bug, it may caused by the CPU part.
NVHPC right now should work with the current CUDA setting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We drive NVHPC just like gcc. Nothing to worry about for this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is this resolved? Now we just check for a good c++17 library.
README.md needs an update |
@PDoakORNL FYI, I canceled the workflows from previous commits in GitHub Actions as this PR evolved quickly, I just kept the head commit to avoid competing for resources, see here. |
How about I try this with the nightly build combinations, and if they work we consider this good to merge? |
I tried the nightly build configurations for sulfur. Everything worked except for clangdev (clang version 13.0.0 (https://github.com/llvm/llvm-project 13ccb097258a244498aa760b878a23de721af29f)
|
I'll try with a fresh llvm but I do wonder if anyone else has seen this. Since the problem is with the development compiler we could just ignore it. |
In the above, Intel is 19.1.3.304 |
that commit has been broken. I believe the previous bad commit has been reverted somewhere after this commit. |
Fresh llvm@main install failed via spack due to llvm-omp-device-info tool failure. I think we can call QMCPACK capable for C++17 with this status. |
Spotted a "(I think its actually higher)" that needs to be removed. |
Fixed. |
Start testing in-house |
Start testing in-house |
Test this please |
@PDoakORNL I tried triggering GitHub Action hosted runners, but the results don't propagate to these PR checks dashboard which look messed up. They might have to be launched with a new commit push: |
Start testing in-house |
Proposed changes
Make the default c++ standard 17.
Close #2790
Closes #2699
Still many build recipes to update in the docs, feel free to pitch in on your favorite.
What type(s) of changes does this code introduce?
Delete the items that do not apply
Does this introduce a breaking change?
What systems has this change been tested on?
Checklist