C++: IR translation for binary conditional operator #3307
Merged
Conversation
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
IR generation was not handling the special two-operand flavor of the `?:` operator that GCC supports as an extension. The extractor doesn't quite give us enough information to do this correctly (see github/codeql-c-extractor-team#67), but we can get pretty close. About half of the code could be shared between the two-operand and three-operand flavors. The main differences for the two-operand flavor are: 1. The "then" operand isn't a child of the `ConditionalExpr`. Instead, we just reuse the original value of the "condition" operand, skipping any implicit cast to `bool` (see comment for rationale). 2. For the three-operand flavor, we generate the condition as control flow rather than the computation of a `bool` value, to avoid creating unnecessarily complicated branching. For the two-operand version, we just compute the value, since we have to reuse that value in the "then" branch anyway. I've added IR tests for these new cases. I've also updated the expectations for `SignAnalysis.ql` based on the fix. @rdmarsh2, can you please double-check that these diffs look correct? I believe they do, but you're the range/sign analysis expert.
|
The sign analysis results are either improvements or cases where it was previously right for the wrong reasons. We don't run the range analysis on the same set of tests, so I'm not sure if there's regressions there. I'll check that and then do a proper code review. |
rdmarsh2
reviewed
Apr 21, 2020
Comment on lines
+1906
to
+1908
| // A `ThrowExpr.getType()` incorrectly returns the type of exception being | ||
| // thrown, rather than `void`. Handle that case here. | ||
| expr.getThen() instanceof ThrowExpr |
There was a problem hiding this comment.
https://github.com/github/codeql-c-extractor-team/issues/67 (already linked in the commit message)
There was a problem hiding this comment.
I meant for ThrowExpr.getType(), unless that's something we think users rely on.
cpp/ql/src/semmle/code/cpp/ir/implementation/raw/internal/TranslatedExpr.qll
Show resolved
Hide resolved
cpp/ql/src/semmle/code/cpp/ir/implementation/raw/internal/TranslatedExpr.qll
Show resolved
Hide resolved
rdmarsh2
approved these changes
Apr 22, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
IR generation was not handling the special two-operand flavor of the
?:operator that GCC supports as an extension. The extractor doesn't quite give us enough information to do this correctly (see github/codeql-c-extractor-team#67), but we can get pretty close.About half of the code could be shared between the two-operand and three-operand flavors. The main differences for the two-operand flavor are:
ConditionalExpr. Instead, we just reuse the original value of the "condition" operand, skipping any implicit cast tobool(see comment for rationale).boolvalue, to avoid creating unnecessarily complicated branching. For the two-operand version, we just compute the value, since we have to reuse that value in the "then" branch anyway.I've added IR tests for these new cases. I've also updated the expectations for
SignAnalysis.qlbased on the fix. @rdmarsh2, can you please double-check that these diffs look correct? I believe they do, but you're the range/sign analysis expert.