similar to: bug: cross-compile Clang/LLVM for ARM using Clang/LLVM

Hi James, renato, So how do I download the missing ARM libraries on Ubuntu14.04? I cannot find any available libraries. Best, Liyang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/04dfc553/attachment.html>

Thanks for your immediate reply! And I have confirmed that the LLVM source code can be compiled successfully on Debian on QEMU/X86_64. The remained is to confirm whether the LLVM source code can be compiled successfully on Debian on QEMU/aarch64.? Thanks all the same! Best 2016-11-30 21:15 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On 30 Nov 2016, at 13:12, 李阳

Hello All, I am building llvm-clang tool chain for *arm target* by following the steps from http://clang.llvm.org/docs/CrossCompilation.html *However when I tried following cmake command for build tool chain it gives the error message :* #CC='clang' CXX='clang++' cmake -G Ninja /home/iiita/llvm-exp/llvm -DCMAKE_CROSSCOMPILING=True

Hello All, I am building llvm-clang cross tool chain for arm target, after successful build for Linux host now I am now building toolchain for *arm target*. However, I am getting below error message which seems to be confusing and not getting any idea how to resolve this issue. *Command :* #CC='clang' CXX='clang++' cmake -G Ninja /home/iiita/crossbuild/llvm

This is currently a rough area in our build system, but there are two CMake options you probably need to set. (1) -DLLVM_BUILD_EXTERNAL_COMPILER_RT=On —> This option causes the build to use the just-built clang when building compiler-rt (2) -DCOMPILER_RT_DEFAULT_TARGET_ARCH=??? —> This is where you specify which architecture you want to build the compiler-rt archives and libraries for

Any kind of distribution is OK, the following is what I tried: 1. debian-testing-arm64-netinst.iso 2. debian-8.6.0-arm64-CD-1.iso 3. debian-testing-arm64-DVD-1.iso The launch script doesn't make any output. 2016-11-30 21:05 GMT+08:00 David Chisnall <David.Chisnall at cl.cam.ac.uk>: > On 30 Nov 2016, at 13:02, 李阳 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >

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

Hi all, Anyone who wants to compile the ``LLVM source code`` on ``QEMU`` running the aarch64 operating system? Now I came across the problem: I cannot launch the aarch64 operating system on QEMU? Wish to get help! Thanks in advance! Best, liyang -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hello, I haven't found any relevant info in the docs about this. I'm trying to build LLVM 3.7.1 on OS X but it fails in the configuration phase. Here are the relevant parts of the output: $ cmake -DCMAKE_INSTALL_PREFIX=/Volumes/HD2/jenkins/workspace/LLVMDev/label/osxbuild/miniconda/envs/_build -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=host -DLLVM_INCLUDE_TESTS=OFF

On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. > > Can you confirm the bot has libatomic

Hi all, I compiled the *llvm3.9* source code on the *Nvidia TX1* board. And now I am following the document in the docs/CompileCudaWithLLVM.rst to compile cuda program with clang++. However, when I compile `axpy.cu` using `nvcc`, *nvcc* can generate the correct the binary; while compiling `axpy.cu` using clang++, the detailed command is `clang++ axpy.cu -o axpy --cuda-gpu-arch=sm_53

> > >>> - Once we add vector, should we consider adding other composite >>> types in general, including structs? C++ allows this, but has substantial >>> issues w.r.t. padding. >>> >>> I'd say possibly, but FCAs are poorly supported in the IR in general. I >>> am not willing to block changes for vectors on changes for FCAs.

So it seems that libatomic went missing between build #1379 and #1380, so I don't think this is related to the -std=c++11 failure. Instead it seems likely that the compile test for -std=c++11 is failing due to mis-configuring -latomic. Can you confirm the bot has libatomic installed? -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi. I'm trying to use Clang/LLVM as a cross-compiling toolchain. In previous version of LLVM with the old configure/Makefile building system, I'm able to build Clang/LLVM for target architecture with the host GCC firstly and then use the generated cross compiler to compile the compiler-rt project, and, consequently, I can get a cross compiler as well as the compiler-rt library. However,

FTR, I've disabled libcxx checkout on that particular bot <http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fuzzer> to make it green. The problem remains, of course. :( On Sun, Dec 11, 2016 at 7:23 AM, James Knight <jyknight at google.com> wrote: > On Dec 11, 2016, at 3:33 AM, Eric Fiselier via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > So it

1. Yes, you both are right. My platform is Jetson TX1, AArch64. 2. And I obtain all the necessary files for TX1 by JetPack from the host(X86) and so `nvcc` can work rightly. 3. Althrough I can compile LLVM3.9 on TX1, I can not compile the CUDA program using `clang` tools. The error is "sys/cedfs.h no such file". 2016-10-28 4:07 GMT+08:00 Justin Lebar <jlebar at google.com>:

Hello Peter and Lists, thanks a lot, that way it worked out! The final cmake was cmake -G "Ninja" ../llvm/projects/compiler-rt/ -DCOMPILER_RT_BUILD_BUILTINS=ON -DCOMPILER_RT_BUILD_SANITIZERS=OFF -DCOMPILER_RT_BUILD_XRAY=OFF -DCOMPILER_RT_BUILD_LIBFUZZER=OFF -DCOMPILER_RT_BUILD_PROFILE=OFF -DCMAKE_C_COMPILER=/usr/local/myclang/bin/clang -DCMAKE_AR=/usr/local/myclang/bin/llvm-ar

Hello again! Tried out the small Hello World Setup, worked as intended: root at christian-forschung-virtual-machine:/home/progs# clang -v --target=arm-linux-gnueabihf hello.c -o hello -fuse-ld=lld clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a152c7a4b7ba8f4cb9532ead9a38a7121db43d50) (https://git.llvm.org/git/llvm.git/ 1959ce6f3e01241919968ac1911fd45660239d23) Target:

On 08/02/13 14:42, Renato Golin wrote: [...] > Can you paste the result of a "clang -v -mcpu=CPU file.c" on your box? I > want to see what are the arguments and the assembler/linker it's > choosing to use. What CPU are we talking about? The box itself is an Allwinner A10; armv7l. /proc/cpuinfo says it's got swp half thumb fastmult vfp edsp neon vfpv3. I've been

Hi, I think that Clang erroneously discards a function annotated with __attribute__((constructor)) when flags -Os -fno-common are given. Test case below. What do you think? Thanks. ----8<--------8<--------8<--------8<--------8<--------8<-------- $ cat ctor.c int val; static void __attribute__((constructor)) init_fn(void) { val = 1; } int main(int argc, char *argv[])