- User Since
- Mar 9 2016, 4:07 AM (127 w, 5 d)
Sat, Aug 4
Fri, Aug 3
Completely rewritten: works correctly for modular arithmetic (multiplication), works correctly for truncation (division), only uses integers, no floats.
Thu, Aug 2
Yes, it is working now without the hack.
Copying iterator position for the this pointer of C++ operators from the caller's context to the callee's context is no longer needed.
Wed, Aug 1
Pre-statement check of CXXOperatorCallExpr merged into pre-call check.
Mon, Jul 30
Thu, Jul 26
How much different is a correct this-argument construction context from real argument construction contexts?
Mon, Jul 23
Jul 19 2018
Jul 18 2018
Jul 16 2018
Jul 13 2018
Jul 11 2018
Any news regarding this?
Jul 9 2018
This seems to solve https://bugs.llvm.org/show_bug.cgi?id=32911.
All existing tests pass. I could not find the appropriate test file so I created a new one, but this is probably not the correct way.
Jul 6 2018
Jul 5 2018
Re-upload because of a mistake.
LGTM! But wait for Artem's acceptance before submitting.
Updated according to the comments.
Jul 4 2018
Adding of transition removed since it is part of D47417.
Jul 3 2018
Instead of marking the container alive, now we defer deletion of the container data until all its iterators are cleaned up.
Jul 2 2018
Hmm, then the only solution that comes to my mind is to link iterator positions to container data instead of the container regions. I also have to store a link to the class definition of the container in the container data for the invalidation rules. Container data can then be detached from the container region until the last iterator to the container is clean up. Is it OK?
Updated according to the comments and assertions added to fail the tests without the fix.
Jun 29 2018
Previous rebase was wrong, this is the correct one.
Jun 28 2018
Do the tests pass now because of rL333670?
Jun 27 2018
Updated to work with the latest Constrain Manager patch.
Jun 25 2018
Comment fixed, assertions inserted, new tests added.
Jun 21 2018
I find it a strange behavior that this-expression is sometimes a pointer, sometimes a record declaration. If references are resolved, why are pointers not?
Jun 19 2018
Jun 18 2018
I added extra assertion into the test for the difference. Interestingly, it also works if I assert n-m is in the range instead of m-n. However, I wonder how can I apply such constraint to the difference of iterator positions without decomposing them to symbols and constants.
-(-2³¹) == -2³¹
New warning message, more detailed docs.
Jun 14 2018
Jun 13 2018
Any idea how to proceed?
Jun 4 2018
Jun 1 2018
Did the tests execute? I am not sure. First problem is the the container may become dead before the iterator, so its Begin and End symbols may be inaccessible. This is easy to solve by marking the container of the iterator as live. However, there is a second problem that disables correct tracking of iterators: memory regions are marked as dead, however there are LazyCompoundVals referring to them. Is this maybe a bug in SymbolReaper?
May 31 2018
Maybe if we could apply somehow a [-MAX/2..MAX/2] constraint to both sides of the rearranged equality in SimpleSValBuilder.
Sorry, Artem, but it does not work this way. Even if the symbolic expressions are constrained to [-MAX/4..MAX/4], after rearrangement the difference still uses the whole range, thus m>n becomes m-n>0, where in the false branch the range for m-n is [MIN..0]. Then if we check n>=m the range set is reversed to [MIN..MIN]U[0..MAX] which results UNKNOWN for n-m. It does not solve any of our problems and there is no remedy on the checker's side.
May 30 2018
Oh, it slipped through somehow. Thanks for fixing this!
May 28 2018
I still disagree, but I want the review to continue so I did the requested modifications.
May 25 2018
May 23 2018
Can we continue the discussion here, please? We should involve Devin and/or George as well if we cannot agree ourselves.
Hello! Thank you for addressing this problem. Are these kinds of symbols common in real code? For me it seems very artificial. However, I agree with George, it would be better to have this value as an analyzer option with a default value (of 20).