gccrs: Fix negative bounds in RangePattern being handled incorrectly
#4243
+57
−0
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
Polygonalr
changed the title
RangePattern being handled incorrectly
Polygonalr
force-pushed
the
issue-3659
branch
2 times, most recently
from
0d81649 to
c434d0c
Compare
philberty
reviewed
Oct 20, 2025
…sitive
GIMPLE output for compile/issue-4242.rs:
...
x = 1;
RUSTTMP.2 = x;
_1 = RUSTTMP.2 >= -55;
_2 = RUSTTMP.2 < 0;
_3 = _1 & _2;
if (_3 != 0) goto <D.112>; else goto <D.113>;
<D.112>:
{
RUSTTMP.1 = 2;
goto <D.105>;
}
<D.113>:
_4 = RUSTTMP.2 >= -99;
_5 = RUSTTMP.2 < -55;
_6 = _4 & _5;
if (_6 != 0) goto <D.114>; else goto <D.115>;
<D.114>:
{
RUSTTMP.1 = 3;
goto <D.105>;
}
...
gcc/rust/ChangeLog:
* backend/rust-compile-pattern.cc (compile_range_pattern_bound): Set litexpr
to negative if has_minus is present in the RangePatternBoundLiteral param.
Signed-off-by: Yap Zhi Heng <[email protected]>
Polygonalr
force-pushed
the
issue-3659
branch
from
c434d0c to
2f7aa77
Compare
Polygonalr
force-pushed
the
issue-3659
branch
from
2f7aa77 to
9e2c020
Compare
Checks whether upper bound of range is not lower or equal to the lower bound. gcc/rust/ChangeLog: * backend/rust-compile-pattern.cc(compilePatternCheckExpr::visit(RangePattern)): Add E0579 check to ensure that lower bound is always below upper bound. Signed-off-by: Yap Zhi Heng <[email protected]>
Polygonalr
force-pushed
the
issue-3659
branch
from
9e2c020 to
8ee2b15
Compare
powerboat9
reviewed
Oct 26, 2025
|
|
||
| rust_assert ( | ||
| (TREE_CODE (upper) == REAL_CST && TREE_CODE (lower) == REAL_CST) | ||
| || (TREE_CODE (upper) == INTEGER_CST && TREE_CODE (lower) == INTEGER_CST)); |
There was a problem hiding this comment.
Does 1f32..1.2f32 break anything?
There was a problem hiding this comment.
Triggers an error that shouldn't be triggered lol, maybe we can create a new issue for it.
error: mismatched types, expected ‘f32’ but got ‘<integer>’ [E0308]
7 | 1f32..1.2f32 => 1,
| ^~~~Anyways, 1.0f32..1.2f32 compiles properly and does not trigger E0579 but -1.2f32..-1.0f32 triggers E0579... not sure what went wrong here :/
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Fixes #4242
Fixes #3659
The ICE for #3659 was initially fixed by #4049, but the test case did not throw E0579 as expected. Moreover, the output GIMPLE was found to be wrong (which led to the creation of #4242). This PR aims to fix both issues by correcting parser behavior for
RangePattern-s and adding E0579 error checking.