similar to: [LLVMdev] Inconsistent naming of functions?

Hi, I recently updated to current llvm svn and fixed-up the minor compiler errors I encountered. However, at run-time even my Hello world programs crash with a segmentation fault. A concrete program that crashes on my Linux x86_64 Fedora box is: declare void @__ot_runtime_print_int(i8*, i32) define void @main() { entry: call void @__ot_runtime_print_int(i8* null, i32 12) br label %return

Are you running in the JIT? If not, what assembler are you using? This looks like an issue with encoding the relative PC distance between the call site and the call entry. Notice that the call site is at a very high address (0x7fffff....) while the target is very low. x86_64 can't encode a full 64-bit immediate offset in the call instruction, so depending on how you are generating this code

Hi, I am using current SVN and in the last week or so, something causing the following assertion failure has changed. void llvm::PATypeHolder::addRef(): Assertion `Ty && "Type Holder has a null type!"' failed. The corresponding stack trace is: #0 0x000000339ec332f5 in raise () from /lib64/libc.so.6 #1 0x000000339ec34b20 in abort () from /lib64/libc.so.6 #2

On Jun 17, 2009, at 12:06 PM, Mark Shannon wrote: > Why are there so many undocumented (and as I far I can see) > unnecessary > API changes? They are only seem unnecessary if you don't understand the reason they were made. We don't make change for change's sake :) > Recently there has been: > > 1. > For JIT applications, please include

Hi, Why are there so many undocumented (and as I far I can see) unnecessary API changes? Recently there has been: 1. For JIT applications, please include llvm/Target/TargetSelect.h and call the llvm::InitializeNativeTarget() function before creating an EE. 2. The major CHANGE is: the JIT will no longer be safe for executing threaded applications without first invoking

On 2009-03-25 15:48, Maurice Gittens wrote: > Hi all, > > On my Fedora 10 x86-64 the current svn dies in the following way: > > /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In > function `llvm::TGLexer::getNextChar()': > /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: > undefined reference to >

Maurice Gittens wrote: > Hi all, > > I just svn-updated the 2.5 branch on my machine and I noticed this > warning during the build. > > *** Warning: Linking the shared library > /home/maurice/installation/llvm/Debug/lib/libLTO.la against the non-libtool > *** objects /home/maurice/installation/llvm/Debug/lib/LLVMCppBackend.o >

Hi all, I just svn-updated the 2.5 branch on my machine and I noticed this warning during the build. *** Warning: Linking the shared library /home/maurice/installation/llvm/Debug/lib/libLTO.la against the non-libtool *** objects /home/maurice/installation/llvm/Debug/lib/LLVMCppBackend.o /home/maurice/installation/llvm/Debug/lib/LLVMMSIL.o /home/maurice/installation/llvm/Debug/lib/LLVMCBackend.o

Hi all, On my Fedora 10 x86-64 the current svn dies in the following way: /home/maurice/installation/llvm-dev/utils/TableGen/Debug/TGLexer.o: In function `llvm::TGLexer::getNextChar()': /home/maurice/installation/llvm-dev/utils/TableGen/TGLexer.cpp:71: undefined reference to `llvm::TGSourceMgr::FindBufferContainingLoc(llvm::TGLoc) const'

On Jul 25, 2009, at 5:44 AM, Maurice Gittens wrote: > Assuming that I have a threaded JIT server which has an llvmContext > object > on the stack of every JITting thread in the server. > > When using the 2.5. API like: > C = llvm::ConstantInt::get(llvm::Type::Int32Ty, 0); > > I need to assume that there exists some global llvmContext object > which holds > the

On Jun 17, 2009, at 9:46 AM, Paul Melis wrote: > FWIW, I'm also suddenly experiencing segfaults in code that used to > work > a few days ago (I'm using svn). This may be unrelated to the problem > described below, but perhaps it's the same thing. > > In my case it seems that creating an ExecutionEngine has changed. I > used > to do > > Module* Mod

Hey folks, As you may be aware if you've been watching llvm-commits, I've been working recently on improving the ability to use LLVM across multiple threads. While the goal for now is to be able to hack on multiple Module's in parallel, this has necessitated a larger review of how LLVM interacts with threads. In a recent(-ish) patch, I added a new API:

Hi, On Fri, Jul 24, 2009 at 7:03 PM, Chris Lattner <clattner at apple.com> wrote: > > On Jul 24, 2009, at 9:30 AM, Duncan Sands wrote: > > >> The ones that don't can be static functions on the type class that > >> take a context. For example, Type::Int32Ty needs to become a > >> function > >> that takes a context at some point. > >

This question is a bit of far away future thought: There's traditionally been a fundamental assumption that static compilers are single-threaded. Many build systems assume this and support assigning compilation jobs with one job per processor. If the compiler becomes multi-threaded internally, how should the build system best schedule compilation jobs? deep On Mon, Jun 15, 2009 at 6:16 PM,

+chandlerc, aaronballman, in case there are additional carryovers and/or issues from the review thread which I've left out. I have a patch up for review[1, 2] that attempts to replace LLVM's mutex implementation with std::mutex and std::recursive_mutex. While the patch seems to work, there are questions surrounding whether or not the approach used is correct. I'll try to summarize

I'm sure this is a question asked many times before, but before I'm flamed, let me state that I've spent TWO WEEKS researching and testing this problem. I've read so many "How To's," forum postings, news groups, and "official docs," I should be an expert on Samba by now. It's obscene. I have an external USB drive - Western Digital 160GB USB 2.0 -

I'm sure this is a question asked many times before, but before I'm flamed, let me state that I've spent TWO WEEKS researching and testing this problem. I've read so many "How To's," forum postings, news groups, and "official docs," I should be an expert on Samba by now. It's obscene. I have an external USB drive - Western Digital 160GB USB 2.0 -

I'm sure this is a question asked many times before, but before I'm flamed, let me state that I've spent TWO WEEKS researching and testing this problem. I've read so many "How To's," forum postings, news groups, and "official docs," I should be an expert on Samba by now. It's obscene. I have an external USB drive - Western Digital 160GB USB 2.0 -

Hello All, I'm building an F# binding for LLVM and it seems to be working for the parts of Core and BitWriter that I've tested but I've hit problems with Target/ExecutionEngine. The following test code works with the initializeNativeTarget line commented out like so: <https://github.com/keithshep/llvm-fs/blob/b7050b841108dc703e58563a4cff8845603c950d/test/simpletest2.fs> ...

"Alan Garny" <alan.garny at dpag.ox.ac.uk> writes: > I have built a shared version of LLVM which I am now able to test in my > Qt-based application. It all works fine on Windows, Linux and Mac OS X, > except that whenever I exit my Qt-based application on Windows (everything > is fine on Linux and Mac OS X), I get a message that reads that "this > application