similar to: [LLVMdev] regarding compiling clang for different platform

Hi Venkata, > ./configure --build=arm-linux-androideabi --host=arm-linux-androideabi > --target=arm-linux-androideabi --with-float=hard --with-fpu=neon > --enable-targets=arm --enable-optimized --enable-assertions Renato's suggestion is a good one, but I suspect the immediate problem here is that this configure line is for building *on* an ARM board. You're probably executing

I was wondering if anyone has encountered this issue when cross compiling cuda on Nvidia TX2 running android. The error is In file included from <built-in>:1: In file included from prebuilts/clang/host/linux-x86/clang-4667116/lib64/clang/7.0.1/include/__clang_cuda_runtime_wrapper.h:219: ../cuda/targets/aarch64-linux-androideabi/include/math_functions.hpp:3477:19: error: no matching function

+Artem Belevich <tra at google.com> On Fri, Mar 23, 2018 at 7:53 PM Bharath Bhoopalam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wondering if anyone has encountered this issue when cross compiling > cuda on Nvidia TX2 running android. > > The error is > In file included from <built-in>:1: > In file included from >

Hi, We are rebasing our audio compression subsystem using OPUS rather than SPEEX. The platform is Android but this piece is written in C code: we need to support armv5/armv7/x86 architectures.... and we use the released opus-1.1beta package from here<http://downloads.xiph.org/releases/opus/opus-1.1-beta.tar.gz>. A lot of our OPUS build system + code to drive the audio compression has been

Hello everyone, this is most likely Arm specific, but could affect other targets where there is a somewhat complex relationship between the triple and mcpu option. At present when clang is used as a linker driver for the gold-plugin and when using and an explicit -mcpu is not given to clang, then clang will always generate a -Wl,-plugin-opt=mcpu=<default CPU> where the default CPU is based

On 3/15/2018 9:43 AM, Peter Smith via llvm-dev wrote: > Hello everyone, this is most likely Arm specific, but could affect > other targets where there is a somewhat complex relationship between > the triple and mcpu option. > > At present when clang is used as a linker driver for the gold-plugin > and when using and an explicit -mcpu is not given to clang, then clang > will

On Thu, Feb 13, 2014 at 5:52 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 13:47, Evgeniy Stepanov <eugenis at google.com> wrote: >> Hm, I see that -funwind-tables on arm-linux-androideabi target >> replaces this "cantunwind" with a proper unwind table. >> Hence http://llvm-reviews.chandlerc.com/D2762. > > If Android is

On Thu, Feb 13, 2014 at 5:39 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 13 February 2014 11:35, Evgeniy Stepanov <eugenis at google.com> wrote: >> Unwind table index '.ARM.exidx' at offset 0x818 contains 4 entries: >> 0x5d4 <main>: 0x1 [cantunwind] > > This is exactly what I meant. > > >> because the latter prevent any

Hi, I downloaded the latest NDK (r10) and compiled with the following cmd: *arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0* It still produces assembly with a call to "memcpy". Maybe the -*fno-builtin *is broken also in the latest release. Do you have some other idea that can help here? Thanks, David On Tue, Aug 5, 2014 at 11:00 AM, Jim Grosbach <grosbach at

> On Aug 7, 2014, at 4:12 AM, Anton Korobeynikov <anton at korobeynikov.info> wrote: > >> I downloaded the latest NDK (r10) and compiled with the following cmd: >> arm-linux-androideabi-clang myMemcpy.c -S -fno-builtin -o0 >> It still produces assembly with a call to "memcpy". Maybe the -fno-builtin >> is broken also in the latest release. >

The build for the Android sanitizers is unique in that it needs to link against the Android system libraries to create a shared object and its test suites. The current solution to build ASan is to drop the compiler-rt repo into the llvm source tree and cross-compile the llvm build for Android. This is a bit awkward for few reasons: 1) Not all of llvm can be cross-compiled for Android.

Hi Jim, I have tried "-fno-builtin" but it didn't help. Thanks, David On Tue, Aug 5, 2014 at 12:12 AM, Jim Grosbach <grosbach at apple.com> wrote: > Hi David, > > "-fno-builtin” is probably what you want. > > -Jim > > On Aug 4, 2014, at 2:19 AM, David Sela <sela.david at gmail.com> wrote: > > Clang optimizes code by replacing some parts

IMO having to disable 2/3 of the tests means the patch isn't ready yet. On Fri, Aug 28, 2015 at 9:31 AM, Jason Kim <jasonk at codeaurora.org> wrote: > > > > -----Original Message----- > > From: Renato Golin [mailto:renato.golin at linaro.org] > > > TESTS! > > > Currently, about 2/3 tests for tsan fail/flake on android+aarch64. > > >

> Alexey's approach with CMake sub-projects. I prefer that direction as well, but what I've proposed is a solution that works today. To support cross-compilation, we'll need to loop over each supported arch (llvm-config --targets-built), then loop over each supported triple for each arch (hard-coded map?), and then pair up each triple with a sysroot (system paths provided by the

Clang optimizes code by replacing some parts with efficient library functions. For example the following code: for (i=0;i<size;++i) dest[i]=src[i]; will be compiled to (target=ARM assembly): bl __aeabi_memcpy(PLT) The compile cmd: /usr/share/android-arm-l14-toolchain/bin/clang31 -cc1 -triple arm-none-linux-androideabi -S -target-abi aapcs-linux -target-cpu arm1022e

>> Going back through SVN history, I cannot find any evidence that ARMv6L ever existed. > > Oh, my bad!! I was thinking of ARMv7l... :/ > > Nevertheless, I'll leave you guys to review this one, as I lost touch with the parser a while ago. Ah, I see: ARMv7L is now an alias for ARMv7A. So, if William has to add support for ARMv6L, I'd suggest he adds it as an alias, and

On 10/10/13 22:01, Jakob Stoklund Olesen wrote: > On Oct 10, 2013, at 12:32 PM, Behan Webster <behanw at converseincode.com> wrote: > >> One of the issues the LLVMLinux project is having is with the use of >> named registers in the Linux kernel code. The kernel uses something like >> this in order to assign a C variable name to a register (one for each >> kernel

Hi, I’ve run into a case where `llc -mattr=+soft-float` for "armv7-unknown-linux-androideabi” segfaults, while `llc -float-abi=soft` does not. Similarly if the "target-features"="+soft-float” metadata is embedded, llc segfaults. I fear I’m missing something rather subtle here, could someone help me understand the differences? Cheers, Moritz

The obvious difference is that you're using --enable-optimized and implicitly --disable-assertions. If you run the tests with make check-all VERBOSE=1 'LIT_ARGS=-v ' > logfile and grep for FAILED in logfile, does what's listed there give any more details? (Quite possible in a Release-Asserts build it might not.) Cheers, Dave -----Original Message----- From: cfe-dev-bounces

> Note that ASan tests on Android require llvm-symbolizer binary. That's a really good point. And I see that llvm-symbolizer can't just be pulled into compiler-rt because it has dependencies on DebugInfo, Object, and Support libraries. This throws a big wrench in Alexey's plan to have the native compiler-rt build generate the cross-compiled binaries for all supported targets. We