[cfe-dev] Static Analyzer - tracking values through indirection?

[Jordan Rose]

That's our current strategy—in cases where we don't have a simpler model (such as, say, trivial copy constructors), we simply do an AST-based inline of the called function. There are certainly downsides to this—it's not very scalable, it doesn't work across translation units, and it has a fair bit of overhead—but it's definitely caught more and more bugs over the last year.

We're interested in expanding our IPA support further, but it's a large and difficult problem (as I'm sure you discussed), and it's not where we're choosing to put our efforts right now. Still, function-level inlining with a translation unit is much, much better than nothing. :-)

Jordan


On May 2, 2013, at 11:44 , Gábor Kozár <kozargabor at gmail.com> wrote:

> By function and method inlining, you mean, inter-procedural analysis support via inlining the called methods? That seems like an interesting choice. We were just discussing this today, that is, how to efficiently support inter-procedural analysis, and this was one idea that came up. Good to know that we had a right idea then. :)
> 
> Thanks for the info!
> 
> 
> 2013/5/2 Jordan Rose <jordan_rose at apple.com>
> Ah, yes. Function and method inlining should already be enabled in 3.2, but constructor (and destructor) inlining was not. Hopefully 3.3 will make your life a bit easier!
> 
> Jordan
> 
> 
> On May 2, 2013, at 11:40 , Gábor Kozár <kozargabor at gmail.com> wrote:
> 
>> Hi Jordan,
>> 
>> They are in the same TU, in fact, inside the very same file. I'll be able to give you further details (e.g. the dump()-ed SVals) on Monday.
>> 
>> Can it be that support for same-TU inter-procedural analysis was added after 3.2? We're using clang 3.2 to avoid stability and backward-compatibility issues.
>> 
>> Thanks!
>> 
>> Gabor
>> 
>> 
>> 2013/5/2 Jordan Rose <jordan_rose at apple.com>
>> I think you mean cross-translation-unit analysis. IPA within one translation unit has been supported for a while. Just to be sure, does your example work if you put definitions of DummyTransaction's methods in the same translation unit?
>> 
>> Jordan
>> 
>> 
>> On May 2, 2013, at 8:16 , Gábor Kozár <kozargabor at gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> Never mind this e-mail, I realized that tracking this would involve inter-procedural analysis, which the Static Analyzer currently does not support.
>>> 
>>> Sorry for the spam!
>>> 
>>> Gabor
>>> 
>>> 
>>> 2013/4/30 Gábor Kozár <kozargabor at gmail.com>
>>> Hi,
>>> 
>>> I need to write a checker to make sure that the state of the transaction is checked after commit. This is working fine is basic cases, but it seems to fail when I introduce any level of indirection. For example, consider the following:
>>> 
>>> class TransactionPtr
>>> {
>>> public:
>>>     TransactionPtr(DummyTransaction& tr) : m_tr(tr) {}
>>> 
>>>     DummyTransaction* getTransaction() { return &m_tr; }
>>>     
>>> private:
>>>     DummyTransaction& m_tr;
>>> };
>>> 
>>> int main(int argc, char* argv[])
>>> {
>>>     DummyTransaction tr;
>>>     TransactionPtr trp(tr);
>>>     
>>>     trp.getTransaction()->commit();
>>>     
>>>     if(tr.isSuccessful()) return 0;
>>>     else return 1;
>>> }
>>> 
>>> Running my checker on this reveals that the analyzer has no idea of the connection between trp.m_tr and tr, and so it fails to detect an issue with the above code.
>>> 
>>> I also tried checkBind(), but it is not called in relation to the TransactionPtr trp(tr); line.
>>> 
>>> Is this a known limitation, or am I missing something here? I also tried getBaseRegion(), getSuperRegion(), which didn't lead anywhere. getMemorySpace() on the other hand points to UnknownSpaceRegion.
>>> 
>>> Thanks!
>>> 
>>> Gabor
>>> 
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> 
>> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130502/9ff2e811/attachment.html>