similar to: [LLVMdev] Building sanitizers for Android

> 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

> 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

It does sound like Android is better suited for "honest" cross-compilation, rather than "build compiler-rt for all targets we can find" model. I'm still not convinced that we must require the "ninja install" step. Could we just "ninja clang" and then build the second stage against the first stage build directory? Will this "find_package" thing

Hi Greg, On Wed, Apr 2, 2014 at 2:50 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Alexey, Evgeniy, > > I propose the following steps to unify multi-arch support in compiler-rt: > > 1) The compiler-rt test suite adds "-L${CMAKE_CURRENT_BINARY_DIR}/lib" > to its 'clang' variables. This way we can test the sanitizers without > installing any libs

On Thu, Apr 3, 2014 at 5:04 AM, Greg Fitzgerald <garious at gmail.com> wrote: > > we would still want to use compiler-rt test-suite in a standalone mode, > to test fully built/installed toolchains, > and even GCC. > > Sounds good. > > > > Clang driver links the static xsan runtimes from a hardcoded > > paths in Clang resource directory, and doesn't

Hey Guys, I'm working on a project in Android related to System-level Audio DSP Effects for Tuning Android Audio. I want to leverage Faust ( https://faust.grame.fr/) to allow users to program their own filters. Faust provides a libfaust implementation which includes a JIT Compiler which leverages LLVM and seems to be the best path for me to use. Unfortunately I'm having problems

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

Hi, I am new to LLVM I want to use llvm and clang on Android, I have downloaded android toolchain and did the configure for llvm using the following commad ./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 and was getting the error "checking

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

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

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

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

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

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

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

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

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

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