similar to: [LLVMdev] libc++ and compiler_rt license change

Hi; This is on Linux/x86-64, I get this at stage1: make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' Makefile:6: make/config.mk: No such file or directory Makefile:7: make/util.mk: No such file or directory Makefile:16: *** Refusing to build with empty ProjObjRoot variable. Stop. make[2]: Leaving directory

ping? Still fails on 3.1 branch. On Tue, Apr 17, 2012 at 5:35 PM, İsmail Dönmez <ismail at namtrac.org> wrote: > > Hi; > > This is on  Linux/x86-64, I get this at stage1: > > make[2]: Entering directory `/home/abuild/rpmbuild/BUILD/llvm/stage1/projects/compiler_rt' > Makefile:6: make/config.mk: No such file or directory > Makefile:7: make/util.mk: No such file or

On Oct 29, 2010, at 8:45 AM, Roman Divacky wrote: > hi! > > To continue the inflow of good news this week, let me announce that > clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! > > This includes things like booting kernel, gnu libstdc++, clang/LLVM > itself and many other components that make up FreeBSD operating system. > > I personally consider

hi! To continue the inflow of good news this week, let me announce that clang -integrated-as (ie. ELF part of MC) compiles all of FreeBSD! This includes things like booting kernel, gnu libstdc++, clang/LLVM itself and many other components that make up FreeBSD operating system. I personally consider this a milestone where -integrated-as should become the default for ELF/{x86_64,i386}. Many

> On Jul 29, 2016, at 2:19 AM, David Chisnall <david.chisnall at cl.cam.ac.uk> wrote: > > On 29 Jul 2016, at 05:11, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> What I meant by “different problem" is that “downstream users” for instance don’t need to commit, that makes their problem/workflow quite different from an upstream developer

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Mehdi > Amini via llvm-dev > Sent: Friday, July 29, 2016 10:02 AM > To: David Chisnall > Cc: llvm-dev at lists.llvm.org; Bruce Hoult > Subject: Re: [llvm-dev] [RFC] One or many git repositories? > > > > On Jul 29, 2016, at 2:19 AM, David Chisnall >

> On Jul 29, 2016, at 11:07 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > > > >> -----Original Message----- >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org <mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of Mehdi >> Amini via llvm-dev >> Sent: Friday, July 29, 2016 10:02 AM >> To: David Chisnall >> Cc:

I don’t know what you mean by dealing with the merging, I don’t expect any difficulties, you need to elaborate. What I don’t see you addressing here is why this should be more of a problem in the monorepo case (as it was implied in the email I was answering to). Your answer made it sound like you thought the monorepo would solve all downstream problems ("I don't know what you mean… I

Hello, I've been working on implementing some basic functionality in order to use the llvm profiling functionality inside of a kernel (the Xen hypervisor). The only functionality I'm interested in is being able to reset the counters, get the size of the data, and dump the data into a memory buffer. I have to admit I haven't been able to find a lot of documentation about how this data

On Wed, Oct 25, 2017 at 09:13:54AM -0700, Xinliang David Li wrote: > On Wed, Oct 25, 2017 at 12:26 AM, Roger Pau Monné via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > Hello, > > > > I've been working on implementing some basic functionality in order to > > use the llvm profiling functionality inside of a kernel (the Xen > > hypervisor).

On Fri, Aug 04, 2017 at 04:03:35PM -0600, Jonathan Roelofs wrote: > > > 1) Pick a directory as your sysroot > > ~/arm-sysroot > > > > > 2) Install the libc headers there (without having built it) > > What I did was mv musl-*/include ~/arm-sysroot/usr/include. > > I think you need to copy them, not move them. On a new directories and fresh untar of musl, I

Dear LLVM developers, Hello, I'm trying to find a way of cross-compiling my c code against Baremetal Cortex-M device (so target triple will be arm-none-eabi) only using LLVM/Clang, and not using anything from GNU (ld or libc). I'm doing this to know which one of LLVM/clang and GCC produces smaller flash image size because saving flash is a big deal in our projects. 1) When I just follow

On 22 October 2014 19:24, Jonathan Roelofs <jonathan at codesourcery.com> wrote: > I do compiler_rt + libc++abi + libc++ + clang (with a custom ToolChain) testing > of libc++ on bare-metal ARM.... so it is possible. Perhaps you mean to say that > it's not possible to test libunwind on arm-linux when using compiler_rt? Yeah, it's hard and clumsy, not impossible. Basically,

On Mar 28, 2014, at 3:32 PM, Bob Wilson <bob.wilson at apple.com> wrote: > There are new conflicts several times a day, on average. I rebased them on Wednesday on top of svn 204791. If you want to try them out, it would be best to roll back to that revision. > > I’ll rebase them one more time when we commit them, but it’s such a moving target (and takes a fair bit of work), that

So, we’ve had this conversation a few times, and I wanted to coalate a status report for all the interested parties. Here's the outstanding work and my (not necissarily correct) view of the status and importance of each one: * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable - There are patches on the bug that we should review, test, and land * Bug 14109 - CMake

I've got a patched LLD 5.0.0 like this: diff --git a/deps/lld/COFF/Driver.cpp b/deps/lld/COFF/Driver.cpp index 854c3e69..8bab1c11 100644 --- a/deps/lld/COFF/Driver.cpp +++ b/deps/lld/COFF/Driver.cpp @@ -1030,7 +1030,7 @@ void LinkerDriver::link(ArrayRef<const char *> ArgsArr) { if (!Args.hasArgNoClaim(OPT_INPUT)) { fixupExports(); createImportLibrary(/*AsLib=*/true); -

Yes, I would hate for some library implementer to either interpret the standard differently or simply not consider the issue of recursive parallelism at all and end up with an implementation that doesn't support it (not that unlikely considering it went 1.5 years through committee as you said and the topic never came up). On Wed, May 17, 2017 at 7:25 AM Bryce Lelbach <balelbach at

Even without a concrete use case, I agree that it's absolutely imperative for the standard to require this of a conforming implementation. It's going to be the source of so many problems otherwise On Fri, May 12, 2017 at 9:14 AM Hal Finkel <hfinkel at anl.gov> wrote: > > On 05/12/2017 11:00 AM, Scott Smith wrote: > > On Fri, May 12, 2017 at 12:52 AM, Bryce Lelbach

http://llvm.org/docs/LangRef.html#linkage-types says: Globals with “linkonce” linkage are merged with other globals of the same name when linkage occurs. This can be used to implement some forms of inline functions, templates, or other code which must be generated in each translation unit that uses it, but where the body may be overridden with a more definitive definition later. Unreferenced

There has been a lot of progress since I first sent out an email recapping the status of replacing autoconf, so I thought I’d send an update. Completed: * Bug 15493 - No option to build shared libLLVM-version.so in CMake * Bug 12157 - llvmconfig.cmake.in make cmake installations not relocatable * Bug 18722 - Option to use CMake with libc++ to compile clang * Bug 21560 - Add support to cmake for