similar to: [LLVMdev] library functions

On 5/23/11 1:05 PM, George Baah wrote: > Hi, > I am writing a pass which is supposed to ignore library functions. Is > there a way to > distinguish functions declared and defined by a developer from > non-local functions (library functions)? > Thanks. There is no reliable way to do this, but there are several heuristics that will probably work well in practice. When

I see that some of the system header-file definitions have the internal keyword. For example, define internal void @__cxx_global_var_init() section "__TEXT,__StaticInit,regular,pure_instructions" { entry: call void @_ZNSt8ios_base4InitC1Ev(%"class.std::ios_base::Init"* @_ZStL8__ioinit) %0 = call i32 @__cxa_atexit(void (i8*)* bitcast (void

Hi there, I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. I don't know if this is an LLVM or Clang issue, from looking at the IR (see below) it looks like the destructor is being tied to cxa_atexit, and I wonder if that is not called by

On Fri, Sep 9, 2011 at 1:36 PM, Graham Wakefield <wakefield at mat.ucsb.edu> wrote: > Hi there, > > I'm having trouble getting ExecutionEngine->runStaticConstructorsDestructors(module, true) to actually trigger static destructors in my code. The static constructors however do get called. > > I don't know if this is an LLVM or Clang issue, from looking at the IR (see

Hi, I'd like to fix PR19590, which is about llvm.global_ctors containing functions that end up being empty after optimization (which causes the linker to add useless init_array entries to the output binary). globalopt removes empty functions from llvm.global_ctors, but by the time the function becomes empty globalopt has already run and it doesn't run again. I'm wondering what the

Hello, Jeff. You wrote Saturday, January 22, 2005, 3:57:28 AM: JC> Reid, the binary/text mode is a valid issue. This set of flags worked for me: std::ios_base::out | std::ios_base::trunc | std::ios_base::binary Yes, there are open issues with std::ios_base::binary, but llvm are not affected with them now. JC> I have successfully used a bytecode file on Windows that was created JC> on

I've read that LLVM can convert from C++ to C code. So I've used it in such a way: I'm Windows-user so I used MinGW. I employed this file as the test: llvm-hello.cpp: #include <iostream> int main(int argc, char* argv[]) { system("pause"); return 0; } result of "llvm-g++ C:\llvm_hello.cpp -o C:\llvm_hellopp.exe" worked just fine. as a result of

Thanks for the suggestion, Andre. I downloaded GNAT GPL 2007, and followed the directions on your web page. Now I get a lot of C++ errors. In fact, the output I captured to a log file is over six megabytes just from the start of the problem command to the termination of the make. I'm obviously not going to include it all here, but the command and the first few errors are copied below.

That's because instructions have a location associated with them, not a compile unit. -eric On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. > > George > > On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: >> >> Here is

Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) *string getFileDirectory*(*const* Instruction &I){ MDNode *MD = I.getMetadata("dbg"); DICompileUnit compileUnit(MD); return compileUnit.getDirectory().str(); } George On Wed, Oct 3, 2012 at 12:40 PM, Eric Christopher <echristo at gmail.com>wrote: > Without knowing the code that you've written

Hmmm, but it has a getDirectory function. -G On Thu, Oct 4, 2012 at 3:50 PM, Eric Christopher <echristo at gmail.com> wrote: > That's because instructions have a location associated with them, not > a compile unit. > > -eric > > On Thu, Oct 4, 2012 at 12:46 PM, George Baah <georgebaah at gmail.com> wrote: > > I used DILocation instead of DICompileUnit and

You should probably think of the DIFooBar constructors like reinterpret-casts, not "go find the thing I actually want" functions. If you hand DICompileUnit() a node that is not a compile-unit metadata node, it's not going to tell you that you goofed. If you _did_ have a CU metadata node, then DICompileUnit's getDirectory() would work just fine. But you don't. --paulr

I used DILocation instead of DICompileUnit and it works. Hmmm, interesting. George On Thu, Oct 4, 2012 at 1:33 AM, George Baah <georgebaah at gmail.com> wrote: > Here is the code. I am running on llvm 3.1 on Lion (Mac 10.7.4) > > *string getFileDirectory*(*const* Instruction &I){ > > MDNode *MD = I.getMetadata("dbg"); > > DICompileUnit

Yeah, It looks like I am doing exactly what's in Dwarf*.cpp files, yet I am getting blanks. George On Tue, Oct 2, 2012 at 2:10 PM, Eric Christopher <echristo at gmail.com> wrote: > On Tue, Oct 2, 2012 at 11:00 AM, George Baah <georgebaah at gmail.com> wrote: > > Hi Guys, > > How does one get the directory of the compilation unit in llvm? > > I am using

Hi Eric, > llvm-main.o: In function `__static_initialization_and_destruction_0': > /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: > undefi\ > ned reference to `std::ios_base::Init::Init()' > /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../../include/c++/4.3.2/iostream:77: > undefi\ > ned reference to `std::ios_base::Init::~Init()'

I mean an llvm Pass that transforms switch statements into if statements. For example, if I have code with switch statements then running the pass will convert all switches to ifs in the bytecode. George On Mon, May 6, 2013 at 4:20 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "George Baah" <georgebaah at gmail.com> > >

Hi Folks, Is a java frontend still being developed for llvm? George -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120726/95b28fc7/attachment.html>

No, Chris, I'm not buying that argument, due to I've tweaked /usr/include/types.h a little bit, so the configuration and compilation of the cfrontend would be correct: /* * 64bit type for BSD compatability */ #ifdef __GNUC__ typedef long long int quad_t; typedef unsigned long long int u_quad_t; typedef long long int int64_t; typedef unsigned long long int u_int64_t;

Without knowing the code that you've written and the IR that you're running on I'm not sure what I can do to help you. -eric On Wed, Oct 3, 2012 at 9:32 AM, George Baah <georgebaah at gmail.com> wrote: > Yeah, It looks like I am doing exactly what's in Dwarf*.cpp files, yet I am > getting blanks. > > George > > On Tue, Oct 2, 2012 at 2:10 PM, Eric

Hi guys Is some one able to explain me, why these errors emerge: gmake[2]: Entering directory `/usr/local/src/llvm/lib/VMCore' Compiling AsmWriter.cpp AsmWriter.cpp: In function `void WriteConstantInt(std::ostream&, const llvm::Constant*, bool, std::map<const llvm::Type*, std::string, std::less<const llvm::Type*>, std::allocator<std::pair<const llvm::Type* const,