Skip to content
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

-indvars miscompilation of Qt #1387

Closed
asl opened this issue Nov 28, 2006 · 5 comments
Closed

-indvars miscompilation of Qt #1387

asl opened this issue Nov 28, 2006 · 5 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla miscompilation

Comments

@asl
Copy link
Collaborator

asl commented Nov 28, 2006

Bugzilla Link 1015
Resolution FIXED
Resolved on Feb 22, 2010 12:41
Version 1.5
OS All
Attachments Source file [qapp.ll], Opt output [qappl.out.ll]

Extended Description

Consider the input file qappl.ll. Look into bb101 and next BBs. This code
corresponds to the following code in cpp (this is extract from Qt):

for (i=0; (UINT)mouseTbl[i] != msg.message || !mouseTbl[i]; i += 3)
    ;
if (!mouseTbl[i])
    return false;
type = (QEvent::Type)mouseTbl[++i];
button = mouseTbl[++i];

qappl.out.ll is output from opt -indvars. We have:

    %tmp107 = seteq uint %tmp103, %tmp106           ; <bool> [#uses=1]
    br bool %tmp107, label %cond_next109, label %bb98

cond_next109: ; preds = %bb101
%exitcond = setne uint %indvar, 0 ; [#uses=1]
br bool %exitcond, label %bb98, label %bb114

%tmp103 corresponds to mouseTbl[i], %tmp106 - to msg.message. %indvar
corresponds to i/3.

Let us assume, that they equals, when i!=0. We have:

%tmp107 = true => branch to cond_next109 => %exitcond = true => branch to bb98

And we have infinite loop here :(

@asl
Copy link
Collaborator Author

asl commented Nov 28, 2006

assigned to @lattner

@lattner
Copy link
Collaborator

lattner commented Nov 28, 2006

Devang, can you take a look at this when you get a chance? Thx,

-Chris

@lattner
Copy link
Collaborator

lattner commented Dec 19, 2006

Devang, any news on this one?

@lattner
Copy link
Collaborator

lattner commented Jan 7, 2007

Reduced testcase:

static const char foo[] = "\0abc";

int test(int J) {
int i;
for (i = 0; i == 0 || foo[i] != 0; ++i)
;
return i;
}

void main() {
printf("%d\n", test(0));
}

$ llvm-gcc t.c -S -o - -O0 -emit-llvm | llvm-as | opt -mem2reg -instcombine -indvars -adce | lli
0
$ gcc t.c
$ ./a.out
4

@lattner
Copy link
Collaborator

lattner commented Jan 7, 2007

Fixed. Testcase here: Transforms/IndVarsSimplify/2007-01-06-TripCount.ll

Patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070101/042170.html

-Chris

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit to clementval/llvm-project that referenced this issue Jan 17, 2022
Improve TODO messages:

- `genLocation()` was used instead of `getCurrentLocation` in many places that
intended to print the current location. Rename it to `genUnknownLocation()` to avoid
confusion in the futur.
- Thread/Compute the location when possible instead of using TODO_NOLOC.
- Ensure the location is set when entering not yet implemented
constructs (toLocation() might return an empty location in case the
construct is the first of an anonymous program)
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla miscompilation
Projects
None yet
Development

No branches or pull requests

2 participants