similar to: [LLVMdev] Debug build

On Sep 23, 2010, at 10:48 PM, Jonas Paulsson wrote: > gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) /Jonas In this case you're using debug info generated by gcc 4.3.2. - Devang [ cc'ing list for the benefit of others] > > From: Devang Patel [mailto:dpatel at apple.com] > Sent: Thursday, September 23, 2010 7:23 PM > To: Jonas Paulsson > Cc:

On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. > > Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4

On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to propose that trunk always have a version number which is in > between versions used by the previous release branch, and before the > versions used in the next release

On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: > Hi Jack, this occurs because you compiled LLVM with clang (right?) and > dragonegg is compiled with the same flags used to compile LLVM (it is > an llvm-config bug in my opinion that llvm-config output includes these > kinds of optional flags). Duncan, Yes. I believe both fink and MacPorts now default to the clang

Tobias Grosser wrote: > On Wed, 2009-07-15 at 00:20 +0200, Tobias Grosser wrote: >> Hi, >> >> I started to work with llvm and liked the CFG dotty printer a lot. >> However there was none for the dominance trees. >> >> I implemented dotty printing for dominance trees Great! I'm a huge fan of graphviz integration in the compiler. > And here is the

Hi Jack, can you please open a bug report asking that llvm-config only provide the minimum set of flags needed to compile code that interfaces with LLVM, rather than (as now) all kinds of unneeded flags such as -g and warnings. Thanks, Duncan. On 07/12/12 18:55, Jack Howarth wrote: > On Fri, Dec 07, 2012 at 06:20:37PM +0100, Duncan Sands wrote: >> Hi Jack, this occurs because you

Hi, I started to work with llvm and liked the CFG dotty printer a lot. However there was none for the dominance trees. I implemented dotty printing for dominance trees and introduced these new flags: -dot-dom : Print dominance tree of function to 'dot' file -dot-dom-only : Print dominance tree of function to 'dot' file (with no function

Hello, LLVM provides several ways to visual IR structure straight in its core - Function::viewCFG() to render control flow graph, then -view-* options to llc to render various stages of transforming to machine code. However, I wasn't able to find a way to render complete DAG visualization of normal IR - which besides CFG would also show dataflow (and other flows, if any). What people use to

Hi Rehman, if I understand right the plugin works fine if you compile it with -fvisibility=hidden, and replace LLVM_GLOBAL_VISIBILITY in llvm-backend.cpp with __attribute__ ((visibility("default"))). Since LLVM_GLOBAL_VISIBILITY is a macro that expands to __attribute__ ((visibility("default"))) if you are not on mingw32 or cygwin, and your gcc version is at least 4, that

Here's what the doxygen page has for viewCFGOnly() : /// viewCFGOnly - This function is meant for use from the debugger. It works /// just like viewCFG, but it does not include the contents of basic blocks /// into the nodes, just the label. If you are only interested in the CFG /// this can make the graph smaller. /// void viewCFGOnly() const; Which indicates that no arguments are

Hey everyone, I want to call F.viewCFG() from within the Hello.so shared library runOnFunction() function, but I keep getting: opt: symbol lookup error: ../../../Debug/lib/LLVMHello.so: undefined symbol: _ZNK4llvm8Function7viewCFGEv while using: "opt -load ../../../Debug/lib/LLVMHello.so -print /temp/llvm/KellyTest/test.bc" I assume this means that I need to statically link in

Hi Hisham, Most likely the basic blocks are the headers of two different loops. Try running viewCFG() on the function in question to see if this is the case. Tom ----- Original Message ----- From: "Hisham Chowdhury" <hisham_chow at yahoo.com> To: llvmdev at cs.uiuc.edu Sent: Wednesday, June 16, 2010 7:22:00 PM GMT -05:00 US/Canada Eastern Subject: [LLVMdev] Loopinfo Analysis

Hi Brandon, > Did you have issues with the Verifier complaining about function-local > metadata after moving blocks? Did you find a good solution for this? > It looks like you are moving blocks or instructions with attached metadata to another function. Some metadata is function-specific, so the verifier complains because the instruction/BB and the metadata don't belong to the

Hello all, I am getting an undefined reference to Function::viewCFG() I have a function list iterator F and I am trying to get the CFG through F->viewCFG(); other function calls through the F pointer are working. - I have included the libraries: pthread, ffi, dl, m, LLVMAsmParse, LLVMCore, LLVMSupport, LLVMSystem. - I have dot and gv in my path, and I have reconfigured and rebuilt LLVM

Hi, I am using latest sources on GCC (gcc4.5_branch), LLVM and dragonegg. I am able to build all three bits though unsuccessfull in building. Already done obvious things - checked out the sources as per defined in "Getting the development version" on dragonegg.llvm.org - Modified the llvm-backend.cpp in dragonegg to make available the global plugin_is_GPL_compatible publically -

Hello, I wanted to try the new c++ stuff, ie clang-3.2, libc++ and libcxxrt, so I used poudriere to build a jail setup for that ( WITH_LIBCPLUSPLUS=yes in src.conf, CXXFLAGS+=-stdlib=libc++ and libsupc++.so.1 libcxxrt.so.1 in libmap.conf ), and started to build my normal set of packages ( see desktop.list ). Please note that I also have WITH_NEW_XORG=yes and WITH_KMS=yes, as well as using the

Hi, I'm trying to compile some apps with the new llvm-gcc4 on amd64 linux to .bc files, rather than to the native code. The same process I used to build those apps before with llvm-gcc3 doesn't work: 1) export CC=llvm-gcc CXX=llvm-g++ CFLAGS="-g -fno-inline" CXXFLAGS="-g -fno-inline" 2) cd <whatever-app>; ./configure 3) make CFLAGS+=-emit-llvm

I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4 months from now. Since some people use and release snapshots of clang from trunk (e.g. the Android NDK), it'd be

Hi, I would be happy to give it a try :-) The fact that AA was added at a later point explains the situation a bit, as much fewer SUs should end up in RejectMemNodes without it. RejectMemNodes is bad in that it mixes all the SUs together again, after having gone through the work of separating them by analyzing their underlying objects. It is also very confusing to have two "stages" of

Hi Jonas, I won’t have time to look at it this week after all. I’ll try to do that next week. If you do not hear back from me by end of next, do not hesitate to ping me! Cheers, -Quentin > On Apr 22, 2015, at 9:32 AM, Quentin Colombet <qcolombet at apple.com> wrote: > >> >> On Apr 21, 2015, at 11:49 PM, Jonas Paulsson <jonas.paulsson at ericsson.com