similar to: NULL ptr dereferences found with Calysto static checker

New version of Calysto reports a warning that looks like a bug to me: ------------------------------------------ Possible NULL-ptr deref (vc27053): @/work/projects/llvm/tools/Calysto/IfaceSpecs/clib.c:1823 Bug: ?? Explanation: choose_dh (dh.c:111) calls fopen twice (@120). If the first call to fopen fails (returns NULL), but the second one succeeds, fgets (@129) is called with f==NULL.

Seung, On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > Ok. Note that LLVM can represent irreducible loops. You can handle > this through code duplication. > -Chris If you are willing to invest more effort into a more complicated analysis, in many cases you can even avoid code duplication. See this paper for details: @inproceedings{erosa94taming, author = {Ana M.

Hi, I have this piece of code: tm = local ? localtime(&curr) : gmtime(&curr); if (!tm) return NULL; which translates into something like: ---------------------------------------------- entry: %iftmp.0 = alloca %struct.tm*, align 8 %tm = alloca %struct.tm*, align 8 ... // Declares iftmp.0 as iftmp.0 call void @llvm.dbg.declare( { }* %iftmp.0, { }* bitcast

On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > Seung, > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > Ok. Note that LLVM can represent irreducible loops. You can handle > > this through code duplication. > > -Chris > > > If you are willing to invest more effort into a more complicated analysis, > in many cases you

Daniel, On 8/30/07, Daniel Berlin <dberlin at dberlin.org> wrote: > On 8/29/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > Seung, > > > > On 8/25/07, Chris Lattner <sabre at nondot.org> wrote: > > > Ok. Note that LLVM can represent irreducible loops. You can handle > > > this through code duplication. > > > -Chris >

Hi all, I have the same problem. My guess is that when a structure is passed as a parameter, you cast it into an array for optimization reasons (less parameters, less stack space). This is, certainly, a reasonable optimization, but makes inter-procedural static analysis more complex. Is there a way to disable it (my guess is that this should be doable by passing some parameter to llvm-gcc)? If

Hi all, After a long time, I've updated to new LLVM. Everything compiles fine (which is great), but I see that compiling/linking into bitcode files still hasn't been solved in a satisfying way. Until that gets resolved, I'm sending an updated script, that will do the trick. Usage: cd $LLVM_PATH/libexec/gcc/x86_64-unknown-linux-gnu/4.0.1/ mv collect2 llvm-collect2 copy the attached

Signed-off-by: krishnaiah bommu <krishnaiah.bommu at intel.com> --- moduli.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/moduli.c b/moduli.c index 578fc48..c1fa484 100644 --- a/moduli.c +++ b/moduli.c @@ -153,12 +153,14 @@ static int qfileout(FILE * ofile, u_int32_t otype, u_int32_t otests, u_int32_t otries, u_int32_t osize, u_int32_t ogenerator, BIGNUM *

Hi, Apart from the Calysto project ( http://www.cs.ubc.ca/~babic/index_calysto.htm), is there any other static code analysis tool based of the LLVM framework ? Calysto may be great but it seems that the source is not available (yet?). I was quite excited by Oink/Elsa few years ago but the project is almost dead even if the C++ parser is far from being complete. It seems to me that everything is

Hi everybody! I recently started using llvm in a project on inferring additional information about pointers based on their types, casts, etc. The following simple example is giving me a headache :): typedef struct { int a; short b, c; int d, e, f; } foo; void bar(foo f) { short s; s = f.b; } int main(void) { foo p; bar(p); } Because llvm doesn't allow structures and arrays

>> It has a section on "structural analysis" that you will find useful. >> >> Why do you want "for statements"? >> > > Thank you for this info, Chris. > I'm doing this 'cause I'm making a backend for a virtual machine > assembly has an instruction which is very similar to 'for' statement. > I know this seems quite

---- Original message ---- >Date: Fri, 24 Aug 2007 22:23:39 -0700 >From: Chris Lattner <sabre at nondot.org> >Subject: Re: [LLVMdev] constructing 'for' statement from LLVM bitcode >To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > >On Aug 24, 2007, at 10:07 PM, Seung Jae Lee wrote: > >> Do you have any idea on how I can construct

I am also trying to build llvm-gcc4 and llvm as you are on amd64 linux. I am currently running into the error "Did not get a target machine!" on the first file compiled by xgcc. Did you encounter this error at all? Also, what distribution did you use? GCC version, and target triple? Thanks, -Chandler Carruth On 12/10/06, Domagoj Babic <babic.domagoj at gmail.com> wrote: >

On 4/9/07, Domagoj Babic <babic.domagoj at gmail.com> wrote: > > > Traditionally, such analyses have been considered too expensive to be > practical, and were mostly an academic curiosity. The core of the > problem is the lack of adequate automated decision procedures which > could quickly determine whether a set of constraints is satisfiable or > not, and if it is

I''m trying to add an RSS feed to my app, and am going through the Rails Recipes chapter on doing so. I get the following error when I request the feed: undefined method `gmtime'' for #<DateTime: 1963061961/800,0,2299161> ... 7: xml.pubDate CGI.rfc1123_date(@posts.first.created_on) Any idea what''s up? Pat

Unless I'm missing something, the problem lies directly with the fact that you are trying to do a link-stage operation with the GCC frontend. GCC, by default, probably runs "ld" or another system linker, which grabs the executable from binutils. This linker hasn't been modified (yet) to include support for .bc files, but you're compiler is emitting byte code to the *.o files.

Hi all, I spent several hours today trying to compile llvm-gcc4 from svn and llvm from cvs on amd64 linux. In the case anyone else decides to try the same, this could ease your pain: 1) check out llvm, llvm-gcc 2) create llvm-obj llvm-gcc-obj export LLVM_INSTAL=<install_dir> cd llvm-obj export LLVM_OBJ=`pwd` ../llvm/configure --prefix=$LLVM_INSTALL --enable-debug-runtime 4) At one point,

On Sep 29, 2006, at 2:05 PM, Domagoj Babic wrote: > > Check out scc_* iterators. Also note that the call graph > is not aware of the indirect calls, so you will need to write your > own CG implementation if you need to handle function pointers > soundly. > Chris, is this true? If so, it seems like a bad property for the CallGraphSCCPass framework. --Vikram

Hi all, On 11/28/06, Reid Spencer <rspencer at reidspencer.com> wrote: > * Venue: West Coast, USA. Probably either San Francisco Bay Area or > Seattle > * Time Frame: Post 2.0 release, summer 2007 > * Topics: Anything related to use or development of LLVM I'd vote for Seattle. The costs of organization should be lower than in the Bay Area. > * An indication of how

t_strftime and variants now .......................................... : ok test-time-util.c:123: Assert failed: strcmp(t_strftime(RFC2822_FMT, gmtime(&ts)), exp) == 0 test-time-util.c:124: Assert failed: strcmp(t_strfgmtime(RFC2822_FMT, ts), exp) == 0 t_strftime and variants fixed timestamp .............................. : FAILED timings 0