C++: Range analysis guard improvement#20584
Merged
paldepind merged 2 commits intogithub:mainfrom Jan 12, 2026
Merged
Conversation
a4d2455 to
ba29a0a
Compare
297f62d to
61f30c9
Compare
61f30c9 to
c4f9212
Compare
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR improves how bounds are adjusted for integral types in C++ range analysis. Instead of simply adding/subtracting 1 to adjust bounds from fractional values like -0.5 to 0.5, it now properly handles the conversion to integer bounds by using floor operations to compute more accurate integer bounds.
Key changes:
- Introduces new helper functions
adjustLowerBoundIntegralandadjustUpperBoundIntegralfor proper bound adjustment - Replaces simple arithmetic adjustment with floor-based calculations that handle fractional bounds correctly
Reviewed Changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| SimpleRangeAnalysis.qll | Adds new adjustment functions and updates bound calculation logic for integral types |
| RangeAnalysisUtils.qll | Adds toString method to RelationStrictness class and improves documentation |
| test.c | Adds new test cases for inequality-derived integer bounds |
| upperBound.expected | Updated test expectations reflecting improved bound calculations |
| ternaryUpper.expected | Updated test expectations for ternary expressions |
| ternaryLower.expected | Updated test expectations for ternary expressions |
| lowerBound.expected | Updated test expectations reflecting improved bound calculations |
Contributor
Author
|
I'm putting this PR back in draft. I have an internal PR that adds new |
c4f9212 to
3a13588
Compare
Contributor
Author
|
I've rebased the PR and updated it to use the new |
Contributor
Author
|
Thanks for reviewing :) |
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
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.
This PR changes how bounds are adjusted for integral types.
As an example, if we have a strict lower bound
> 1on an integer then the lower bound is 2. As of now, this is achieved by adding 1 to the lower bound. However, this adjustment is not always correct.For this guard, where
eis an integer:We deduce a lower bound of
> -0.5and after adding 1 we get0.5. For such a fractional lower bound adding 1 doesn't really make sense. This PR tweaks this slightly, such that the lower bound ends up being 0. A similar adjustment is made for upper bounds.I ran into this when debugging a performance issue where this showed up. This adjustment didn't fix the performance issue, but I think it's still worthwhile.
Per-commit review is suggested
— I also snuck in a few orthogonal changes.I think the DCA report seems uneventful.