Explicitly set cxx standard for GNU compiler#599
Closed
Conversation
Newer versions of the GNU compiler uses a may use newer c++ standards which could cause cmake compilation tests to yeild false-positive results when it says that a c++17 feature exists and is usable by when the target/using is actually building c++14 targets.
Contributor
Author
|
Closing this since it will be addressed by #600 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Newer versions of the GNU compiler uses a may use newer c++ standards which could cause cmake compilation tests to yeild false-positive results when it says that a c++17 feature exists and is usable by when the target/using is actually building c++14 targets.
The problem caused the
check_cxx_source_compilescheck (https://github.com/LLNL/Umpire/blob/develop/cmake/SetupCompilerFlags.cmake#L14-L27) to produce a false-positve because it was using runningg++without any-std=c++14argument. The default c++ standard for 11.2.0 g++ is 17. So, this check would succeed and the Umpire source code would fail to compile later since it was using-std=c++14NOTE: This PR contains one fix and one hack. The hack needs to be resolved before this may be considered for merging.NOTE 2: I've attempted to address the hack mentioned above by separating out the initialization of the compiler family variables to a different (new) file and am including that file earlier in BLTMacros.cmake.
This problem was reported by a spack user here and is internally documented in an Umpire jira ticket here.