similar to: Problem about compiling the LLVM source code on QEMU running the aarch64?

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, 李阳

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

Yes, I think so. And here I only want to know the result whether QEMU running the aarch64 operating system can compile the LLVM source code? Thanks! 2016-11-30 20:57 GMT+08:00 Renato Golin <renato.golin at linaro.org>: > On 30 November 2016 at 12:41, 李阳 via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > Now I came across the problem: I cannot launch the aarch64

Hi renato, 1. The command above is followed by the guide[ HowToCrossCompileLLVM.rst ] and I specify some path(ex. <path-to-host-bin>). 2. The including x86_64 libraries is added because of some missing libraries(ex. "error: Host compiler appears to require libatomic, but cannot find it"). As I have found that the bugs needed to dealt with is some ARM-dependent libraries, I

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

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>

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

On 16 December 2014 at 21:12, Gundapaneni, Sumanth <sgundapa at quicinc.com> wrote: > The point here is, if you are not building for Android. > You will hit this patch with cmake configuration -DCOMPILER_RT_TEST_TRIPLE=aarch64-linux-gnu > > + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") > + test_target_arch(aarch64

Hi Renato, Are you sure? Armv8-a is aarch32, not aarch64. Something smells fishy there. Cheers, James On Thu, 18 Dec 2014 at 08:03, Renato Golin <renato.golin at linaro.org> wrote: > On 16 December 2014 at 20:29, Christophe Lyon > <christophe.lyon at linaro.org> wrote: > >> I don't see "-march=aarch64" is a valid flag on either LLVM or GCC. >

(+llvm-dev) My question was whether your host machine, the one which is running the compiler, is ARM (as opposed to x86 or POWER). The header you pointed to was in "aarch64-linux-gnu", which made me think you might be on an ARM system. If you are not running linux x86, it is not likely to work. If you are running linux x86, we will need much more details about your system in order to

Kostya, Christophe, I'm running the full tests on AARch64 and the only RT test that fails is: UndefinedBehaviorSanitizer-Standalone :: TestCases/Float/cast-overflow.cpp The problem seems to be a trap in __sanitizer::internal_memchr() while trying to handle __ubsan::__ubsan_handle_float_cast_overflow(). I haven't looked at it in detail, has anyone seen this? Is UBSan meant to run on

Hi Gabor, I noticed that one particular test fails intermittently on the AArch64 bot: http://lab.llvm.org:8011/builders/clang-native-aarch64-full FAIL: Profile:: instrprof-set-filename-then-reset-default.c Some times on stage1, others on stage2, others no fail at all. All the commits during these builds are not related to profiling or AArch64, so I believe this has something to do with the

On 5 May 2016 at 13:01, Bradley Smith <Bradley.Smith at arm.com> wrote: > Allowing -march=aarch64/arm64 is somewhat misleading I think, -march is used > for specifying an architecture version to target whereas aarch64/arm64 don’t > convey any information to that effect, does it mean armv8a, armv8.1-a, etc? Hi Bradley, That's a good point. But also, what does "armv8a"

Hi, I wonder if this is a valid flag in either clang/gcc. The flag in question is "-march=aarch64". I verified with latest tip and neither clang nor gcc fail to recognize this flag. This piece of code is in cmake/config-ix.cmake in compiler-rt repo. + elseif("${COMPILER_RT_TEST_TARGET_ARCH}" MATCHES "aarch64") + test_target_arch(aarch64

Hi Adhemerval, Some UBSan tests are timing out randomly. http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full ex: http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/902 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/894 http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/906

Hi, A64 versus A32/T32 code generation is controlled by the -target option which I don’t believe is under discussion here. James On 18 May 2016, at 13:17, Bruce Hoult <bruce at hoult.org<mailto:bruce at hoult.org>> wrote: Note that armv8a modifies the A32 and T32 instruction sets, and is therefore an important -march option for 32 bit code. Therefore armv8a can not be used to imply

I'd like to mention that test does not allocate 30TB, it allocates 1TB, the rest, ~20TB, is reserved (but not actually used) for ASan shadow memory, it should not be a problem by itself. The test on your bot failed because it tried to reserve 27TB of memory, which is more than set by ulimit earlier in this test. I do not immediately see why it wants to reserve that much shadow for AArch64

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F:

I knew I'd regret leaving that option in for the MIPS port back in 99. Basically this is the only acceptable way for mcpu to exist, but should never have been added to the GCC aarch64 port at all since there's no compatibility with existing build systems to worry about. I would still like you to show this mythical piece of software that needs this compatibility. -eric On Jan 8, 2014 3:06

On 26 August 2015 at 20:13, Jason Kim <jasonk at codeaurora.org> wrote: > I had been discussing the TSAN on android/aarch64 issues with the folks at thread-sanitizer at googlegroups.com for several months now. I had not explicitly been including llvm-dev (and you), and that was a mistake on my part. Palm-on-face? :-( Yup, that would have saved a lot of emails... :) > Patch Size!