similar to: Fail to install llvm/clang on debian

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 filesystem

> 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

> 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

llvm[2]: Compiling FileSystemStatCache.cpp for Release+Asserts build FileSystemStatCache.cpp: In static member function 'static bool clang::FileSystemStatCache::get(const char*, stat&, bool, int*, clang::FileSystemStatCache*)': FileSystemStatCache.cpp:63: error: 'openFileForRead' is not a member of 'llvm::sys::fs' make[2]: ***

----- 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

With reference to the following thread: http://lists.llvm.org/pipermail/llvm-dev/2016-January/094100.html I am having the same issue. First I did a git pull of all the relevant directories and then doing a cmake: cmake -DLLVM_ENABLE_DOXYGEN=ON -DLLVM_ENABLE_WERROR=OFF -DLLVM_TARGETS_TO_BUILD="X86" ../llvm and followed by make: [ 22%] Built target LLVMVectorize [ 25%] Built target

hello all, I have install xen on my system, the booting is no problem, and I type xm-list show following words: # xm list Name ID Mem VCPUs State Time(s) Domain-0 0 2953 4 r----- 7214.7 that means my xen is ok, but when I want to start xend start, print following words: bash: xend: command not

hello all, I have a question of how to install the DomU, I used virt-install, typed VM ''s name. After asked the following question, What is the install location? I typed /media/ubuntu/-9.04-desktop-i386.iso it didn''t work, show the following messages Could not find an installable distribution at

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

Hi, The test-suite expects to be built standalone but it looks like you have it in the same tree as LLVM. You'll need to remove it. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Peter Teoh via llvm-dev Sent: 28 February 2016 14:31 To: llvm-dev at lists.llvm.org Subject: [llvm-dev] [cfe-dev] [3.8 Release] We have branched With reference to the following thread:

----- 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

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.

I think we've just forgotten to update that part of the instructions. Having the test-suite at projects/test-suite was harmless to the old autoconf and LLVM 3.7.x's cmake builds because it didn't actually cause the test-suite to be built. The CMakeLists.txt that have been added to the test-suite now cause it to be built by LLVM's build system which introduces the build failure. We

Hi, I try to build llvm-trunk with Cmake (gcc-5.3.0 is necessary for CUDA) on my "SUSE Linux Enterprise Server 12.2 (x86_64)". svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co http://llvm.org/svn/llvm-project/cfe/trunk clang svn co http://llvm.org/svn/llvm-project/polly/trunk polly cd clang/tools svn co

*TL;DR* We propose some non-trivial refactoring in Clang and LLVM to enable further work on Flang driver. *SUMMARY* We would like to start extracting the driver/frontend code from Clang (alongside the code that the driver/frontend depends on, e.g. Diagnostics) and move the components that could be re-used by non-C-based languages to LLVM. From our initial investigation we see that these

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

Hi, all, I am planning to add clang-tidy checkers for my company. How to add a new module for my company? Please help, thanks in advance. I try to copy files from cert module, and rename cert to Misra, then add a rule named "m-0-1-1" by ./add_new_checker.py. then I run ninja check-clang-tool, but my case is failed due to below error Running ['clang-tidy',

Oh, so it looks like I hit a bit of a wall there :-) I’ll take a look thanks. That bug talks about R_ARM_THM_CALL which I assume are thumb related. Will your implementation fix also R_ARM_CALL errors? > On 28 Jun 2017, at 17:15, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > The LLD ARM port doesn't currently support range extension thunks,

> On 27 Jun 2017, at 13:25, Peter Smith <peter.smith at linaro.org> wrote: > > Hello Alessandro, > > Despite the statement in the HowToCrossCompileLLVM guide "If you’re > using Clang as the cross-compiler, there is a problem in the LLVM ARM > back-end that is producing absolute relocations on > position-independent code (R_ARM_THM_MOVW_ABS_NC), so for now, you