similar to: [LLVMdev] How to obtain CFG using llvm-gcc?

This is rather off-topic for LLVM, it's a C programming question and the C answer is: you can't. C doesn't expose any way to find the upper limit of 'Ptr' you just have to keep track of what size you used yourself. On Sun, Dec 15, 2013 at 6:22 PM, 李永超 <lyc364 at gmail.com> wrote: > Hi, > How can I obtain the upper bound of a pointer in the code? For example, I

Hi, How can I obtain CFGs using llvm-gcc? After reading the documentation at LLVM`s homepage, I didn`t found anything related to this. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131122/eeca9247/attachment.html>

Hi, getMetadata(“dbg”) returns NULL for such a small program as follows: int main(){ char a[10], b[2]; if(a[0] != 0 && a[1] != 0){ strcpy(a, b); } return 0; } The compiling command is: llvm-gcc --emit-llvm -g -c ./src.c I also tried the solutions I found through Google: http://stackoverflow.com/questions/14943447/llvm-line-number-of-an-instruction

Hi, How can I obtain the upper bound of a pointer in the code? For example, I have a pointer Ptr which points to a block of memory that is allocated by malloc, say, Ptr = malloc(size); Then what should I do if I am going to get the upper bound of the memory block that is pointed to by Ptr in the runtime? Thanks, Ben -------------- next part -------------- An HTML attachment was scrubbed...

Sir, your answer put me in starting situation.As I told I am not able to generate .bc file of hello.cpp(the pass file) as it is giving errors when I use clang -emit-llvm -c hello.cpp -o hello.bc.So please if you can help me. Thanks On Fri, Jun 6, 2014 at 3:48 PM, Dan Liew <dan at su-root.co.uk> wrote: > On 5 June 2014 10:12, Prashanth Sharma <cs13m1017 at iith.ac.in> wrote:

Thanks Eli. It's not introducing loops, just unstructured conditionals (e.g. X's in the control-flow graph, rather than diamonds). You can see it using "opt -view-cfg" on the code below. Sounds like it's not a bug. Thanks for the info. - Mark ; Tail duplication yielded this code, which has non-structured control flow. ; Note that "then.i2" and

On Thu, Jul 24, 2008 at 2:00 PM, Mark Leone <markleone at gmail.com> wrote: > Is irreducibility a problem for existing LLVM passes? There aren't any LLVM passes that expect a reducible CFG at the moment; of course, some passes are more effective with reducible CFGs. > It looks like > there was once an open project for a pass to make irreducible graphs > reducible. Was that

I just realised I forgot to reply to this. Thanks for advise, it's good to know. Thanks, Dan Liew. On 30 August 2013 16:25, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Aug 30, 2013 at 7:53 AM, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: >> Hi, >> >> I'm trying to write a small piece of code that inlines all calls to a >> particular

On 20 December 2013 05:39, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: > Hi Rafael and other LLVM devs, > > I'm currently upgrading a project that uses LLVM that links a bitcode > archive (a C library) with a module. Originally we used > Linker::LinkInFile() but that was removed by r172749. So I started > looking for an alternative and I found >

Hi Daniel, Thanks for your answer. > I am considering fixing the bug in the LLVM CommandLine library but is > going to be a long time before I can look at it. So don't wait for me > to do that. > Ok, ok, but, if you end up fixing this, please keep me post. > If you are really desperate to have the command line options in the > way you want they you may need to implement

Hi, I've been spending a bit of time fixing up building and installation of the Doxygen and Sphinx documentation for CMake. There are more fixes in the pipeline (none for autconf/make system, I'm not interested in fixing that) but I started wondering if any testing was done to check that documentation builds correctly for LLVM and its various subprojects. I'm not particularly

Hi, I'm confused about the entry and exit blocks of an LLVM CFG. I understand that every CFG has one and only one entry block, and this is confirmed by the existence of the getEntryBlock function in the Function class. But what about exit (a.k.a. return) blocks? At first I assumed that LLVM CFGs have one and only one exit block, too, but the following code is a counter-example:

> > Message: 4 > Date: Tue, 12 Aug 2008 13:23:52 -0700 > From: "Bill Wendling" <isanbard at gmail.com> > Subject: Re: [LLVMdev] A case where llvm created different cfg for > same code > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Message-ID: > <16e5fdf90808121323g1ae2a2e3lb6c5bd62521df621 at mail.gmail.com> >

On 17 September 2014 16:34, Mueller-Roemer, Johannes Sebastian <Johannes.Sebastian.Mueller-Roemer at igd.fraunhofer.de> wrote: > I'll have another look tomorrow. Thanks. > IMO, it is unnecessary clutter. It will fail if ${ZLIB_LIBRARIES} or ${ZLIB_INCLUDE_DIRS} are used anyways as they will be set to NOTFOUND. Or we go back to a silent-fail solution: Fair enough. I've never

I am getting a segmentation fault as soon as I touch the Basic block *b value defined as :  std::string getPHIAssigns(const PHINode *PH)  { const BasicBlock *b = PH->getParent();    errs() << b->size(); where as getPHIAssigns is being called from               for (BasicBlock::iterator ins=b->begin(), e3=b->end(); ins!=e3; ++ins, ++l) // get instructions                

Hi, This is a proposed fix for bug 16847 [1]. It is essentially the patch provided by Martin Nowack in the bug report but I have added a test case and an ifdef macro around the modified code in Process::GetMallocUsage() The issue seems to be that the ptmalloc2 allocator used in glibc (in my case 2.19) does not include mmap()'ed memory in mallinfo.uordblks and so mallinfo.hblkhd needs to be

On 13 February 2013 19:37, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Is anyone currently working on overhauling the command-line processing code? > I'm currently doing some work on the CommandLine library but I don't think my work is going to help you. I'm current working on... - Allowing declared command line options to be put into categories to allow a

Dear Trevor, I'm too lazy to convert your .dot file into a graph file, but I'll make some comments anyway. :) First, LLVM does not guarantee that a function has a single exit block. Multiple basic blocks can have a return instruction as their terminator instruction. There is a pass (Unify Function Exit nodes i.e., -mergereturn <http://llvm.org/docs/Passes.html#mergereturn>)

Hi Surinder, I don't see anything obviously wrong with your code. I suggest that (1) you build LLVM with assertions enabled, (2) you run the verifier on your bitcode, and (3) run your program under valgrind. Ciao, Duncan. > I am getting a segmentation fault as soon as I touch the Basic block > *b value defined as : > > std::string getPHIAssigns(const PHINode *PH) > {

Changing it to only apply to the MinGW-Makefiles generator is maybe the safest method. Though you would have to check if MINGW is only set in the Mingw-Makefiles generator and not In the MSYS-Makefiles or Cygwin generators (should be in the docs). -- Johannes S. Mueller-Roemer, MSc Wiss. Mitarbeiter - Interactive Engineering Technologies (IET) Fraunhofer-Institut für Graphische Datenverarbeitung