search for: virtualfilesystem

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> > {anonymous}::RealFileSystem::openFileForRead(const llvm::Twine&)’: /home/yubo/git/llvm/tools/clang/lib/Basic/VirtualFileSystem.cpp:262:46: error: ‘OF_None’ is not a member of ‘llvm::sys::fs’ sys::fs:...

I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some f...

> 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 moment. Cheers, Rafael

...ase ask for it to wait. It requires designing how the > linker > script parser and the thin archive system will fetch new files as > they > are found. 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? -Hal > > Also, please consider what is so bad about writing a file. If your > language has anything like...

...onable to also expose the external path here? (of course being an optional) > > Sam McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> ezt írta (időpont: 2018. nov. 15., Cs, 12:02): > I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. > (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) > > https://reviews.llvm.org/D54277 <https://reviews.llvm.org/D54277> proposed adding a function to VirtualFileSystem to get the underlying "real file" path...

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.

...s designing how the > > linker > > script parser and the thin archive system will fetch new files as > > they > > are found. > > 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? Sorry my negligence, but what does Clang VFS layer provide? Looking at the header file, it looks to m...

...t; script parser and the thin archive system will fetch new files as > > > > they > > > > are found. > > > 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? > > Sorry my negligence, but what does Clang VFS layer provide? Looking > at t...

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,

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