similar to: [LLVMdev] LLVM test fails with "gnu/stubs-32.h: No such file or directory"

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joachim Durchholz wrote: | Subject says it all. | | Looking in /usr/include/gnu, I find stubs-64.h and stubs.h, but no | stubs-32.h. | This is probably related to my machine running a 64-bit install of | Ubuntu. I'm not sure whether this should be rectified in Ubuntu or LLVM. You don't have i386 and x86-64 devel packages installed. Ask your

Benjamin, > It seems that LLVM bytecode doesn't have a builtin type for "pointer-sized > integer". You should use TargetData to provide a size of pointer. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the expected footprint of a tool using the LLVM JIT? I have created a simple project that uses the LLVM C++ API to JIT calls to XPCOM method signature... it works well, but the component DLL is very large (Linux x86-74, 5.8MB optimized and stripped). Is this normal? Am I linking to "too much" or not using the correct link flags?

On Mon, 3 Dec 2007, Benjamin Smedberg wrote: > What is the expected footprint of a tool using the LLVM JIT? Right now it's ~1.5 to 2M for one platform, at least on darwin. > I have created a simple project that uses the LLVM C++ API to JIT calls > to XPCOM method signature... it works well, but the component DLL is > very large (Linux x86-74, 5.8MB optimized and stripped). Is

Hello! I'm trying LLVM for generating code and I found something I cannot figure out or find in the documentation: I'm doing something like this to call "sin" from std: std::vector<const Type*> params; params.push_back( Type::FloatTy ); FunctionType *FT = FunctionType::get( Type::FloatTy, params, false); Function *F = new Function( FT, Function::ExternalLinkage,

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm a LLVM newbie who's started experimenting with the JIT, and I have a couple questions relating to LLVM and the runtime JIT: I'm going to post them as separate messages to avoid getting threads tangled up. I want to call a C++ function from a function that was JITted at runtime. I'm starting with HowToUseJIT.cpp as a base for

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anton Korobeynikov wrote: > Benjamin, > >> It seems that LLVM bytecode doesn't have a builtin type for "pointer-sized >> integer". > You should use TargetData to provide a size of pointer. Sorry, perhaps I was not clear. When JITting code it's not hard to figure out the size of a pointer and use the equivalent

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Lattner wrote: > Finally, there is still a lot that can be done to reduce code size. For > example, building a JIT links in the .s file printers in, and they have > non-trivial size (big string tables etc). It would be great to refactor > the code to avoid things like this. I wouldn't be surprised if we could > shrink the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been reading the headers and http://llvm.org/releases/2.1/docs/ProgrammersManual.html and I'm still confused about a pretty fundamental point... who is expected to clean up various objects when we're finished with them, and when? Let's say I've created a module, retrieved a bunch of types, created a function, a basic block,

Package: xen-3.0 Version: 3.0.4-1-1 Severity: important Hi, Your package is trying to build 32 bit binaries on amd64, and fails with the following error: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory If you want to build 32 bit binaries on 64 bit arches, you need to build depend on gcc-multilib on those arches. Kurt

Package: xen-3 Version: 3.1.0-1 Severity: important Hi, Your package is failing to build on amd64 with the following error: In file included from /usr/include/features.h:345, from /usr/include/stdint.h:26, from ../rombios_compat.h:8, from tcgbios.c:24: /usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory make[6]: ***

PLEASE help me - this is making me insane. Can anyone suggest any reasons for this behavior? It occured previously, then went away and is now back. In Task.rb (where task is an active record subclass) def clear_schedule puts "clearing schedule for task" scheduled_end_date= nil #reset the scheduled end date save halt.

I got it to work by changing scheduled_end_date= nil to self.scheduled_end_date= nil. I believe these statements should be equivilent. I don''t know Ruby/Rails well enough to know when, if or why that should matter. Can someone educate me please? I want to believe this framework is ready for production work, but silently dropping data is a very big problem. I expect that I''ve

Hi all, I’m running Xen 4.1 on a couple of NetBSD dom0s and NetBSD’s pkgsrc provides both the xl and xm tools for working with Xen 4.1. I understand that xl is the new way of doing things, but I can’t get it to create my guests the way I want and the main symptom of this is that the text console isn’t available. When I create a guest with xl it starts up qemu-dm (which xm doesn’t do) and I get

So, I was attempting to use qemu snapshots with backing stores. The QEMU docs (http://wiki.qemu.org/Documentation/CreateSnapshot) make it sound like you simply point your qemu at the snapshot after it's creation, and you're golden. When attempting this with libvirt, though, it fails. I created a snapshot using the above tutorial. the resulting file is disk.0, and a qmeu-img info on it

On Mon, Oct 19, 2015 at 12:39 PM, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Am 19.10.2015 um 19:40 schrieb Daniel Berlin: >> On Mon, Oct 19, 2015 at 10:24 AM, Joachim Durchholz via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >>> Am 19.10.2015 um 17:25 schrieb Chris Lattner via llvm-dev: >>>> >>>>

Am 01.11.2011 05:59, schrieb Marc J. Driftmeyer: > Then this complaint about build times and extra CPU cycles when you're > living in a world of systems soon to average 16GB of RAM, 4-12 cores and > GPUs that would make any old Animator dream back in the '90s really > makes me laugh. Not disagreeing about the rest, but here I have to. In today's projects, full rebuilds

On Mar 3, 2008, at 2:49 AM, Joachim Durchholz wrote: > Hi all, > > I found enough to explain the behaviour that I encountered. If I'm > correct, the bugs are just in the dejagnu-based test machinery, not in > LLVM itself. Yep, I believe that. I haven't been following the whole thread very closely, what specific tests are affected here? Before making any significant and

Hi all, I'm wondering what the comparative status of llvm-gcc4.0 vs. llvm-gcc4.2 is. Can anybody tell? (A URL would be fine, I may have been just too dumb to find it.) Regards, Jo

I've been tossing around some ideas about high-level backends. Say, have LLVM emit Perl code. Sounds whacky but isn't. It's good for the first bootstrapping phase in environments where you don't have a C compiler, where you don't have a cross-compiled binary for download, but you can execute Perl. It also makes a great inspect-the-sources-with-an-editor stage for aspiring