similar to: "devirtualizing" files in the VFS

> On Nov 15, 2018, at 3:34 AM, Whisperity <whisperity at gmail.com> wrote: > > I am really not sure if adding real file system functionality strictly into the VFS is a good approach. This "ExternalFileSystem" thing sounds weird to me. The `ExternalFileSystem` was an attempt to provide a more limited interface while exposing the "external" path in a way that

Hello, Maybe this is not a bugs. But i fail to install llvm many times and different machine(debian os). First, i follow the instruction: http://cilium.readthedocs.io/en/latest/bpf/#llvm But during in compiling, i alway get: ... /home/yubo/git/llvm/tools/clang/lib/Basic/VirtualFileSystem.cpp: In member function ‘virtual llvm::ErrorOr<std::unique_ptr<clang::vfs::File> >

Dear All I've made un update to the llvm to the latest. At configuration, I've met some new errors to me, like it needs lldb, lld, dragonegg, llgo and so. However, I've checked them and configuration went on. Now I'm stuck at build stage, specifically at dragonegg. First it could not find gmp.h, I've solved this by installing libgmp-dev. Now, it can't find auto-host.h.

----- Original Message ----- > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Andrew Kelley" <superjoe30 at gmail.com>, "Rui Ueyama" <ruiu at google.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org> > Sent: Tuesday, December 13, 2016 2:30:41 PM > Subject: Re: [llvm-dev] LLD status

> Instead of just waiting, I think we should discuss design requirements. Clang, for example, has a VFS layer too (in include/clang/Basic/VirtualFileSystem.h) which seems independent from Clang. Maybe we want to move it into LLVM and reuse it from both Clang and LLD. Would this VFS layer meet the requirements for an LLD VFS layer too? That is not something I will be spending time at the

I need an atomic pointer exchange, so I took a look at Support/Atomic.h, and the only supported types are 32-bit values. I can't figure out an obvious reason for this other than perhaps nobody ever had need of this yet, but given that this is kind of a low level thing, I thought I should ask first. Is there any reason I should not add 64-bit versions of the atomic functions? Additionally,

On Tue, Dec 13, 2016 at 12:40 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Rafael Avila de Espindola via llvm-dev" <llvm-dev at lists.llvm.org> > > To: "Andrew Kelley" <superjoe30 at gmail.com>, "Rui Ueyama" < > ruiu at google.com> > > Cc: "llvm-dev" <llvm-dev at

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Rafael Avila de Espindola" <rafael.espindola at gmail.com>, > "llvm-dev" <llvm-dev at lists.llvm.org>, "Andrew Kelley" > <superjoe30 at gmail.com> > Sent: Tuesday, December 13, 2016

Andrew Kelley via llvm-dev <llvm-dev at lists.llvm.org> writes: > On Tue, Dec 13, 2016 at 1:06 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: >> >> That said, I think the current our "API" to allow users call our linker's >> main function hit the sweet spot. I know at least a few LLVM-based language >> developers who want