similar to: [LLVMdev] Hi guys and llvmbrains! :P

Whoops, missed the list. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: Jean-Daniel Dupas <devlists at shadowlab.org> > Cc: > Sent: Wednesday, April 18, 2012 10:24 AM > Subject: Re: [LLVMdev] Hi guys and llvmbrains! :P > > > > >> ________________________________ >> From: Jean-Daniel Dupas <devlists

Hi Jean-Daniel On Mon, Oct 19, 2009 at 3:24 PM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > > Le 19 oct. 2009 à 15:05, Kenneth Uildriks a écrit : > FWIW, there is a LLVM bar camp planed in Paris the next month: > > http://barcamp.org/LLVM%20BarCamp%20Paris (French web page) > > > -- Jean-Daniel > Could you please tell me if it will be in French or

Le 20 oct. 2009 à 10:27, Artur Pietrek a écrit : > Hi Jean-Daniel > > On Mon, Oct 19, 2009 at 3:24 PM, Jean-Daniel Dupas <devlists at shadowlab.org > > wrote: > > Le 19 oct. 2009 à 15:05, Kenneth Uildriks a écrit : > FWIW, there is a LLVM bar camp planed in Paris the next month: > > http://barcamp.org/LLVM%20BarCamp%20Paris (French web page) > > > --

On Mon, Apr 29, 2013 at 3:11 PM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Just out of curiosity, what would be the main benefit of this approach vs DKMS which is already widely used ? > Thanks Dupas. I checked DKMS you mentioned, basically DKMS is just a ko and its sources management tool. It's not easy to deploy ko source into target machine, and it's more

Thanks for the info! Yes, the problem is certainly that the JITed code isn't registering its classes, but even after digging through all the runtime code I can't find anything that seems suitable for doing this.. The nearest function I could find was _objc_init_image, but that seems to be for win32! I assume that the way it works must be that clang creates some static data structures

Hello, While working on lld code, I encountered a couple of memory management issues. If lld should be usable as a library, I assume it should not leaks any memory when performing a single link pass (UniversalDriver::link(arc, argv)). Actually, after calling that function, I got some major leaks. I may be wrong, but I think there is 3 major leaks. - One of the main leak is in FileArchive. When

On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org>wrote: > If you want to build a clang version that target x86 and ARM on an x86 > machine and your actual compiler does not support compiling for ARM, you > have to use the just built clang. > Using the just-built-clang will only work if compiler-rt has access to each target's sysroot.

And also, the hook to load/unload image is installed in objc-os.m using dyld_register_image_state_change_handler() function. Le 8 mai 2012 à 15:07, Julian Storer a écrit : > Thanks for the info! > > Yes, the problem is certainly that the JITed code isn't registering > its classes, but even after digging through all the runtime code I > can't find anything that seems

Hello, After I try making a clean build and got the following error: llvm[3]: Compiling EDDisassembler.cpp for Release build In file included from /llvm/include/llvm/Target/TargetSelect.h:38, from /llvm/lib/MC/MCDisassembler/EDDisassembler.cpp:37: /llvm/stage1/include/llvm/Config/AsmPrinters.def: In function ‘void LLVMInitializeX86TargetAsmPrinter()’:

http://wiki.llvm.org/ ? Le 23 mars 09 à 19:04, Bill Wendling a écrit : > So, um...what's the URL for this wiki? > > -bw > > On Mar 23, 2009, at 10:29 AM, Daniel Berlin wrote: > >> Installed it, thanks. >> Seems to work! >> >> 2009/3/23 Misha Brukman <brukman at gmail.com>: >>> On Mon, Mar 23, 2009 at 12:18 PM, Daniel Berlin

On Mon, Apr 29, 2013 at 08:14:57PM +0800, Jovi Zhang wrote: > On Mon, Apr 29, 2013 at 3:11 PM, Jean-Daniel Dupas > <devlists at shadowlab.org> wrote: > > Just out of curiosity, what would be the main benefit of this approach vs DKMS which is already widely used ? > > > Thanks Dupas. > > I checked DKMS you mentioned, basically DKMS is just a ko and its > sources

AFAIK, ld does not use DYLD_LIBRARY_PATH to lookup libLTO.dylib but contains a reference to @executable_path/../lib/libLTO.dylib. The only way I managed to load a different LTO library than the default one is to create a symlink pointing to the actual ld binary (as returned by 'xcrun -find ld') and making sure the library I want to load is placed at ../lib/libLTO.dylib relatively to this

For dogfooding the compiler I normally use is a LTO bootstrap of clang. On linux that is simple to do that since clang passes the correct plugin to the linker. On OS X ld64 uses libLTO.so it finds via DYLD_LIBRARY_PATH. Should clang set that before running the linker? Is there a better way for clang to tell the linker which libLTO.so to use? Cheers, Rafael

Jean-Daniel Dupas <devlists at shadowlab.org> writes: > Le 29 janv. 2011 à 09:33, Mark Lacey a écrit : > >> I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works. >> >> I am wondering if there is a timeline or resources lined up

Jean-Daniel Dupas <devlists at shadowlab.org> writes: >> P.S. Weren't we planning on removing the Make-based build system in >> the next few months a year ago? > > It always lacks some important features, like building compiler-rt > with just-built clang: http://llvm.org/bugs/show_bug.cgi?id=14109 The configure&make build works on more homogeneous environments

Hi Jean-Daniel, My fault, I'm sure, but I don't see the problem yet. Is it possible your version of llvm/Config/AsmPrinters.def has X86 listed twice? - Daniel On Mon, Aug 2, 2010 at 12:43 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After I try making a clean build and got the following error: > > llvm[3]: Compiling EDDisassembler.cpp for

Le 21 juin 2012 à 11:34, Manuel Klimek a écrit : > On Thu, Jun 21, 2012 at 10:43 AM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Jun 20, 2012, at 6:19 PM, Chandler Carruth wrote: > >> On Wed, Jun 20, 2012 at 5:13 PM, Nick Lewycky <nlewycky at google.com> wrote: >> Is there anybody who is certain that our autoconf dependency needs to stay around?

Hello everyone, I started writing/copying some info for an easy optimization pass, only to take a look (like a brush). I think it's going to be necessary to define a standard format for each kind of information (for example, which information for an optimization pass: the analysis it uses in the "see also" section?). 2009/3/23 Jean-Daniel Dupas <devlists at shadowlab.org>

On May 23, 2013, at 10:30 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > On Thu, May 23, 2013 at 6:01 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > If you want to build a clang version that target x86 and ARM on an x86 machine and your actual compiler does not support compiling for ARM, you have to use the just built clang. > > Using the

Just out of curiosity, what would be the main benefit of this approach vs DKMS which is already widely used ? Le 28 avr. 2013 à 18:42, Jovi Zhang <bookjovi at gmail.com> a écrit : > Hi, > > First of all, I didn't study on compiler too much, I'm a Linux kernel developer, > Now I have one idea about compile kernel module by using llvm framework. > > In Linux