search for: builting

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

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:

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

> 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

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,

I've successfully used Peter's patches to get past those relocation errors. On 6/28/17, 9:36 AM, "llvm-dev on behalf of Peter Smith via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Yes it should cover the following relocations: R_ARM_CALL (ARM BL/BLX) R_ARM_JUMP24 (ARM B) R_ARM_THM_CALL (Thumb BL/BLX)

The bottom of the bug has the revision numbers (e.g. D34035). That one corresponds to e.g. https://reviews.llvm.org/D34035 There's also https://reviews.llvm.org/D34634 which contains all of Peter's patches, but it's not going to rebase cleanly once the individual patches start going in. On 6/28/17, 10:56 AM, "Alessandro Pistocchi" <apukfreelance at gmail.com> wrote:

At a guess that looks like your llvm and lld checkouts are not quite in synch. It will be worth updating llvm and lld to top of trunk. I've rebased the consolidated patch https://reviews.llvm.org/D34634 this morning, it might be worth trying that if you are seeing problems. Peter On 29 June 2017 at 22:09, Alessandro Pistocchi <apukfreelance at gmail.com> wrote: > Hi, I tried

Hello, I downloaded LLVM 2.6 and was attempting to compile it with TDM-GCC 4.4.1-tdm2-sjlj + cmake 2.6.4 and this happened: =============Console=================== C:\projects\game-editor\LLVM\build-root>mingw32-make [ 2%] Built target LLVMSystem [ 5%] Built target LLVMSupport [ 7%] Built target tblgen [ 7%] Built target intrinsics_gen [ 10%] Built target LLVMCore [ 12%] Built target

> On 26 Jun 2017, at 16:25, Rui Ueyama <ruiu at google.com> wrote: > > On Sun, Jun 25, 2017 at 6:40 AM, Alessandro Pistocchi via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > Hi, > > I am trying to build a completely GNU free linux toolchain for the raspberry pi. > > I successfully managed to compile llvm and clang

I am unable to compile R packages from source on Ubuntu dapper/edgy. Does anybody have an experience? When I do install.packages("nlme",depend=TRUE), I get following error messages. Can someone help? I get similar messages for any package I try to compile. VR ------------- * Installing *source* package 'nlme' ... ** libs gcc -I/usr/share/R/include -I/usr/share/R/include

On Wed, Mar 8, 2017 at 2:03 PM Sterling Augustine <saugustine at google.com> wrote: > Yes, this is a aspect of the larger problem that clang bootstrap doesn't > work for a cross-compiler. The build (mostly?) assumes that host==target > during the build of clang itself, and then if you want another architecture > also, you run a second build of the target libraries, and

Hi all, I ran ../llvm/configure CC=g44 CXX=g++44 and the exit code was 0, but in config.log I found errors (mostly about missing files) and warnings (mostly about conflicts in builtin functions). I thought maybe the fact I later get compilation errors when running make is related to these. How do I correct these errors? or can they be ignored? The full list of errors from config.log is

On 03/08/2017 04:55 PM, Chris Bieneman via llvm-dev wrote: > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported ways in the LLVM build system to build > compiler-rt with the just-built compiler. > > 1) The legacy way is for if compiler-rt is under LLVM/projects. You > can specify

Hi everyone, I am trying to install colorspace (needed as part of my favourite ggplot2) on R v 2.7.0 running under ubuntu 7.04. The package is provided as source files and the compilation fails as below. I suspect this might be a problem with gcc v3/v4 incompatibility (or anything else), but I don't really know how to resolve it. Any advice will be appreciated - or perhaps somebody has got

I recently updated R 2.10.1 Patched (2010-02-20 r51163) This morning I reinstalled biomaRt using biocLite. Now I can no more connect to biomaRt and even the following instruction is hanging for a while until the same error message pops up. > listMarts() Error in value[[3L]](cond) : Request to BioMart web service failed. Verify if you are still connected to the internet. Alternatively the

Hi All, In this thread we would like to review the built-ins and name mangling approach which we chose for SPIR. Specifically, I think a discussion on the atomics and memcpy should be interesting. *****OpenCL Built-ins Introduction****** OpenCL provides a huge set of utility functions (>6000 built-ins) which are available for the developers of OpenCL. These functions are called built-ins.

I stumbled across what seems to be a bug (to me) in the compiler-rt build: The compiler-rt libraries themselves are built with the host compiler while the tests are built and then linked with the just-built clang. It was my understanding that the goal/intent/need was to have the compiler-rt library build with the just-built clang? Did I misunderstand that?* Sterling: Chandler seemed to think

On Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> wrote: > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported ways in the LLVM build system to build compiler-rt > with the just-built compiler. > > 1) The legacy way is for if compiler-rt is under LLVM/projects. You can > specify

Dear All, I have just updated R to the version 2.6.2 on F8 (with the official F8 rpm). However, when running as root the following command: update.packages(checkBuilt=T) I get a bunch of errors like the ones below. Any ideas? Thanks in advance, Paul ----------------------------------------------- * Installing *source* package 'nlme' ... ** libs gcc -m32 -std=gnu99 -I/usr/include/R