-
Notifications
You must be signed in to change notification settings - Fork 707
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
[C++23] When using C++23, use [[assume]] attribute. #16457
Merged
Merged
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
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.
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 still means that we can't define
DEAL_II_HAVE_CXX23
forgcc-13
without getting in a lot of places (switch constructs) where this macro might be used.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 comes back to the question I asked above that fell through the cracks:
I think what you're saying is that you want us to use the GCC-specific way even if
[[assume]]
is available? Why would we do this? If there's a standard way to do something, we should use it.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 are already using
[[assume(expr)]]
forgcc
but that triggers a bunch of warnings in switch statements.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 may have missed this, but is there an example posted somewhere I could look at?
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'm seeing
for example.
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.
Ah, I see. The code that surrounds this is follows:
I see how a compiler could get confused by this. In other places, of course, we add a dummy
return 0;
after that. I could do this either by hand or by script if you happened to have a log file that has all of the places where this happens.I think it is preferable to clean up our code base if the upside is that we can use a standard C++ feature.
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 our current consensus is to not blanket convert all
Assert
s to assume statements so this wouldn't be an issue.I think it makes much more sense to create a new
AssertOrAssume
macro (or a similar construct) to selectively convert some of the asserts (where we know or anticipate that they have a benefit).This would allow us to simply use the C++23
[[assume()]]
with gcc as suggested in this pull request without working around compiler warnings. And also to drop-Wno-assume
(which already happened).I want to point out that in general a compiler warning tells us that something is going wrong, which, admittedly, can be a defect or deficiency in a compiler. But it is also an indicator that our expectations ("do something useful with this assume statement!") does not match with what a compiler can do (at least at the moment).
So sure, we can make the compiler shut up in the above case... but much more fundamentally what would we gain with an assume statement at this place?
[[assume(false)]]
is a useless statement. But the compiler will need to parse it, run a lexer on it and then decide to do nothing with it.So my suggestion would be to have a
DEAL_II_CXX23_ASSUME
macro with as little workarounds as possible. And we explore how we can use it.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.
FWIW,
[[assume(false)]]
effectively behaves asstd::unreachable()
.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.
@masterleinad You're correct.
Arguably, that might make the whole situation for our
Assume(false, ...)
statements even worse... at least in terms of "debuggability" for the release mode.