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

Minimum c++ std to c++17 #3348

Merged
merged 10 commits into from
Aug 11, 2021
Merged

Minimum c++ std to c++17 #3348

merged 10 commits into from
Aug 11, 2021

Conversation

PDoakORNL
Copy link
Contributor

@PDoakORNL PDoakORNL commented Aug 6, 2021

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

  • New feature
  • Build related changes
  • Documentation changes

Does this introduce a breaking change?

  • No, unless your compiler is old

What systems has this change been tested on?

Checklist

  • Yes. This PR is up to date with current the current state of 'develop'
  • Yes. Code added or changed in the PR has been clang-formatted
  • Yes. This PR adds tests to cover any new code, or to catch a bug that is being fixed
  • Yes. Documentation has been added (if appropriate)

@PDoakORNL PDoakORNL changed the title Minmum c++ std to c++17 Minimum c++ std to c++17 Aug 6, 2021
Copy link
Contributor

@ye-luo ye-luo left a 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.")
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

@ye-luo ye-luo Aug 6, 2021

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Contributor

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.

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@prckent
Copy link
Contributor

prckent commented Aug 6, 2021

README.md needs an update

@williamfgc
Copy link
Contributor

@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.

@prckent
Copy link
Contributor

prckent commented Aug 9, 2021

How about I try this with the nightly build combinations, and if they work we consider this good to merge?

@prckent
Copy link
Contributor

prckent commented Aug 10, 2021

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)
) which turns out to be fresh compiler bug compiling WriteEshdf.cpp .

git_QMCPACK_prckent]$ grep -e "START build configuration" -e "% tests passed" out | sed -e 's/.*configuration//g' -e 's/ Tue.*//g'
 build_gccnew
100% tests passed, 0 tests failed out of 832
 build_intel2020_nompi
100% tests passed, 0 tests failed out of 652
 build_intel2020
100% tests passed, 0 tests failed out of 832
 build_intel2020_complex
100% tests passed, 0 tests failed out of 767
 build_intel2020_mixed
99% tests passed, 1 tests failed out of 749
 build_intel2020_complex_mixed
99% tests passed, 1 tests failed out of 729
 build_gccnew_nompi_mkl
100% tests passed, 0 tests failed out of 652
 build_gccold_nompi_mkl
100% tests passed, 0 tests failed out of 630
 build_clangnew_nompi_mkl
100% tests passed, 0 tests failed out of 652
 build_gccnew_nompi
100% tests passed, 0 tests failed out of 652
 build_clangnew_nompi
100% tests passed, 0 tests failed out of 652
 build_gccnew_mkl
100% tests passed, 0 tests failed out of 832
 build_gccnew_mkl_complex
100% tests passed, 0 tests failed out of 767
 build_gccdev_mkl
100% tests passed, 0 tests failed out of 832
 build_gccdev_mkl_complex
100% tests passed, 0 tests failed out of 767
 build_clangnew_mkl
100% tests passed, 0 tests failed out of 832
 build_clangnew_mkl_complex
100% tests passed, 0 tests failed out of 767
 build_clangnew_mkl_mixed
100% tests passed, 0 tests failed out of 749
 build_gcclegacycuda
100% tests passed, 0 tests failed out of 240
 build_gcclegacycuda_complex
100% tests passed, 0 tests failed out of 254
 build_gcclegacycuda_full
100% tests passed, 0 tests failed out of 240
 build_pgi2021_nompi
99% tests passed, 3 tests failed out of 652
 build_gccnew_debug_mkl
100% tests passed, 0 tests failed out of 832
 build_gccnew_debug_complex_mkl
100% tests passed, 0 tests failed out of 767
 build_clangdev_nompi_mkl
0% tests passed, 652 tests failed out of 652
 build_clangdev_nompi_mkl_complex
0% tests passed, 573 tests failed out of 573
 build_clangdev_offloadcuda_nompi_mkl
0% tests passed, 652 tests failed out of 652
 build_clangdev_offloadcuda_nompi_mkl_complex
0% tests passed, 573 tests failed out of 573

@prckent
Copy link
Contributor

prckent commented Aug 10, 2021

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.

@prckent
Copy link
Contributor

prckent commented Aug 10, 2021

In the above, Intel is 19.1.3.304

@ye-luo
Copy link
Contributor

ye-luo commented Aug 10, 2021

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.

that commit has been broken. I believe the previous bad commit has been reverted somewhere after this commit.

@prckent
Copy link
Contributor

prckent commented Aug 10, 2021

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.

@prckent prckent self-requested a review August 10, 2021 17:39
prckent
prckent previously approved these changes Aug 10, 2021
@prckent
Copy link
Contributor

prckent commented Aug 10, 2021

Spotted a "(I think its actually higher)" that needs to be removed.

@ye-luo
Copy link
Contributor

ye-luo commented Aug 10, 2021

Spotted a "(I think its actually higher)" that needs to be removed.

Fixed.

@ye-luo
Copy link
Contributor

ye-luo commented Aug 10, 2021

Start testing in-house

@ye-luo ye-luo enabled auto-merge August 10, 2021 23:07
@prckent
Copy link
Contributor

prckent commented Aug 11, 2021

Start testing in-house

@ye-luo
Copy link
Contributor

ye-luo commented Aug 11, 2021

Test this please

@williamfgc
Copy link
Contributor

@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: git commit --amend and git push -f <your-remote> drop_c++14.

@ye-luo
Copy link
Contributor

ye-luo commented Aug 11, 2021

Start testing in-house

@ye-luo ye-luo merged commit 5716f3e into QMCPACK:develop Aug 11, 2021
@PDoakORNL PDoakORNL deleted the drop_c++14 branch February 23, 2022 00:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

AFQMC is not C++17 ready Require C++ 17
4 participants