Description
Feature request
Summary of Problem
Given a comparison between a uint and 0 that is known to always be true by definition such as 'a > 0' or 'a >= 0', I believe the compiler should param fold this conditional as it does with other obvious facts. It doesn't currently at present because the overload that handles this case returns 'true' along one branch (when the other arg is a param 0) and calls the execution time comparison in the other branch; so the routine can't be a param routine and can't be folded.
A potential fix is to break the routine into two using a where clause to disambiguate and making the obvious case a param function and the other case not. But this runs into bugs in our handling of where clauses which is another issue (#5236).
Steps to Reproduce
Source Code:
config var x: uint;
if (x < 0) then
compilerError("This should never happen");
Compile command:
chpl foo.chpl
Execution command:
./a.out
Configuration Information
- Output of
chpl --version
: 1.14.0.a771ec7 - Output of
$CHPL_HOME/util/printchplenv --anonymize
: N/A - Back-end compiler and version, e.g.
gcc --version
orclang --version
: N/A - (For Cray systems only) Output of
module list
: N/A
Activity
This is a simple change that adds a test for, and fixes, a bug (issue c…
Merge pull request #5242 from bradcray/quickFixUintExpEquals
Merge pull request #5275 from bradcray/resolveWheresForNonGenericsAnd…
bradcray commentedon Jan 30, 2017
PR #5277 makes an attempt to fix this issue using the new where clause fixes introduced in PR #5275 but is currently failing with three tests.
mppf commentedon Nov 7, 2018
PR #11570 has some related changes. See #11570 (comment)
mppf commentedon Nov 7, 2018
Here is a link to the test we'd like to get to pass for this issue to close: https://github.com/chapel-lang/chapel/pull/5277/files#diff-c60cb09d88210e77db2f5c34662d065d
Merge pull request #11570 from mppf/lifetime-checking-module-scope
Param-fold some < between integers (#25529)
vasslitvinov commentedon Jul 12, 2024
#25529 implements this specifically for
<
.I am leaving this issue open as a request for similar changes to other operators:
<=
>=
>
==
!=
.bradcray commentedon Jul 25, 2024
I hate to look a gift horse in the mouth (particularly one that I requested), but I wonder whether it's worse to support thse foldings only for
<
without adding the symmetric support to>
,<
,>=
, and>=
... (just from a non-orthogonality perspective)vasslitvinov commentedon Jul 25, 2024
@bradcray I do not have an answer to the "is it worse" question. My thinking is (a) if we like what I did in #25529 then we can do the same for the other operators, and (b) feel free to back out #25529 pending (a), if desired.