[cfe-dev] Static Analyzer for template / floating point precision audit?

Sun Jun 7 12:18:43 PDT 2009

Hello!

I had an idea yesterday about a possible use of clang that I'd like to  
discuss and hopefully contribute towards. I want a static analysis  
tool that tells me which types get used in the instantiation of C++  
templates. Perhaps this exists somewhere already but I haven't found  
it yet. Basically I want to see the results of template generation,  
and verify that types aren't getting converted by mistake when I'm  
passing values around between templates and non-template functions.  
Additionally, I want to be able to see where floating point values go  
in and out of the extended precision registers on Intel. To be frank,  
I don't know much about how this works.

My rudimentary understanding of C++ internals is that the template  
declarations and instantiations exist as language elements in the AST,  
but that the actual template 'code'  is generated later. Is this  
correct?

What is the proper nomenclature for all this? I'm looking for words to  
differentiate between the instantiation in the source (ie  
std::pair<int>) and the generated 'code' resulting from lookup, which  
i assume is not actual source. What is that called?

  Do template instantiations modify the AST, do they generate LLVM IR,  
or something else in between?

If the generation step produces something other than AST, does this  
mean my problem is outside of the scope of the static analyzer?

  I think this problem might be best addressed via LLVM IR, because I  
want to to see how well inlined, nested templates flatten out after  
optimization. Is it even possible to get the original source line for  
a piece of optimized IR?

Regarding the floating point precision analysis, i sounds like a tall  
order, but I'd like to hear what you all think. For one thing, it's  
architecture dependent. At what point does the compiled code lose it's  
original source identity?

For an example of the issues I'm talking about, here is an arbitrary  
precision geometry library that gets betrayed by extended precision: http://www.cs.cmu.edu/~quake/robust.pc.html 
. I talked to some compiler engineers at Apple over a year ago, and  
they were proud of how well gcc handles floating point precision, by  
keeping intermediate calculations in the extended registers.  
Nevertheless, it seems to me that sooner or later these values have to  
get reduced down to regular precision. The ideal tool I have in mind  
would be able to show me where the precision loss is happening.

Please let me know if this is something that would be of interest to  
clang developers, and the static analyzer in particular.

Thanks,

George

On Jun 5, 2009, at 10:00 AM, cfe-dev-request at cs.uiuc.edu wrote:

> Send cfe-dev mailing list submissions to
> 	cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> 	cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> 	cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
>   1. Re: Almost there... (Douglas Gregor)
>   2. Re: Almost there... (AlisdairM(public))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 5 Jun 2009 07:45:40 -0700
> From: Douglas Gregor <dgregor at apple.com>
> Subject: Re: [cfe-dev] Almost there...
> To: Sebastian Redl <sebastian.redl at getdesigned.at>
> Cc: cfe-dev at cs.uiuc.edu
> Message-ID: <2C0DC60B-A9C0-4C03-85AC-1B39B55673C6 at apple.com>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>
> On Jun 5, 2009, at 6:20 AM, Sebastian Redl wrote:
>
>> AlisdairM(public) wrote:
>>> Now my last problem - I am getting a couple of compiler errors
>>> trying to
>>> build the CodeGen library, so can't link the final clang-cc.  Are
>>> these a
>>> known issue?
>>>
>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2039:
>>> 'BIalloca' : is not
>>> a member of 'clang::Builtin'
>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2065: 'BIalloca' :
>>> undeclared identifier
>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2051: case
>>> expression not
>>> constant
>>>
>>> ...\clang\lib\CodeGen\CGCall.cpp(1757) : error C2039: 'NoRedZone' :
>>> is not a
>>> member of 'llvm::Attribute'
>>> ...\clang\lib\CodeGen\CGCall.cpp(1757) : error C2065: 'NoRedZone' :
>>> undeclared identifier
>>>
>> Looks like you caught a broken in-between commit. Try simply updating
>> Clang again.
>> If that's not it, I'll have to look at it myself. Been a while  
>> since I
>> built Clang on Windows.
>
> Actually, you'll need to update LLVM. They tend to be developed
> together (NoRedZone was added to both front end and back end in the
> same day), but you need separate "svn update" commands for the LLVM
> and Clang trees.
>
> 	- Doug
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 5 Jun 2009 16:15:39 +0100
> From: "AlisdairM\(public\)" <public at alisdairm.net>
> Subject: Re: [cfe-dev] Almost there...
> To: "'Douglas Gregor'" <dgregor at apple.com>, "'Sebastian Redl'"
> 	<sebastian.redl at getdesigned.at>
> Cc: cfe-dev at cs.uiuc.edu
> Message-ID: <000f01c9e5f0$7d7a2b40$786e81c0$@net>
> Content-Type: text/plain; charset="US-ASCII"
>
>> -----Original Message-----
>> From: Douglas Gregor [mailto:dgregor at apple.com]
>> Sent: 05 June 2009 15:46
>> To: Sebastian Redl
>> Cc: AlisdairM(public); cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] Almost there...
>
>>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2039:
>>>> 'BIalloca' : is not
>>>> a member of 'clang::Builtin'
>>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2065:  
>>>> 'BIalloca' :
>>>> undeclared identifier
>>>> ...\clang\lib\CodeGen\CGBuiltin.cpp(271) : error C2051: case
>>>> expression not
>>>> constant
>>>>
>>>> ...\clang\lib\CodeGen\CGCall.cpp(1757) : error C2039: 'NoRedZone' :
>>>> is not a
>>>> member of 'llvm::Attribute'
>>>> ...\clang\lib\CodeGen\CGCall.cpp(1757) : error C2065: 'NoRedZone' :
>>>> undeclared identifier
>>>>
>>> Looks like you caught a broken in-between commit. Try simply  
>>> updating
>>> Clang again.
>>> If that's not it, I'll have to look at it myself. Been a while since
>> I
>>> built Clang on Windows.
>>
>> Actually, you'll need to update LLVM. They tend to be developed
>> together (NoRedZone was added to both front end and back end in the
>> same day), but you need separate "svn update" commands for the LLVM
>> and Clang trees.
>
> Thanks both.
> The NoRedZone problem has cleared up with an LLVM update as Doug  
> suggested.
> The builtins::BIalloc issue remains, but it is a simple drop-through  
> case
> label in a switch statement, so I'm commenting it out for now and  
> the rest
> seems fine.  The name looks odd anyway - does not match the usual  
> naming
> pattern in use here.
>
> Not sure why this isn't tripping everyone else up though - does not  
> look
> Windows specific to me.
>
> To warm up I'm going to look into implementing C++0x raw string  
> literals, as
> I expect this to be a very localised change.  I think it will be  
> easier to
> do this before looking into the Unicode char types and updating the  
> string
> concatenation rules.
>
> I expect most of this to fall inside the StringLiteralParser class,  
> but
> could someone point me to what starts the scanning for a string  
> literal.
> i.e. the code that recognised " or L" in order to invoke the string  
> literal
> parser?
>
> Thanks muchly,
> AlisdairM
>
>
>
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 24, Issue 8
> **************************************