similar to: [LLVMdev] Cross compile LLVM

Hi; assume i<-10 how can i create a list having key=10 and value=11 list(i=11) generates a list with 'i' [1] 11 and not 10 [1] 11 any help? Thanks _________________________________________________________________ Facebook. :ON:WL:en-US:SI_SB_facebook:082009 [[alternative HTML version deleted]]

> Android runtime is special, we build it in a separate build tree configured with > -DCMAKE_TOOLCHAIN_FILE=$LLVM_CHECKOUT/cmake/platforms/Android.cmake This worked great, thanks! Would you mind tweaking Android.cmake so that I can override the location of the C compiler? The current version forces me to use the just-built-clang and that the new build directory be in a sibling directory.

I am trying to build compiler-rt on a x86_64 machine using clang. Command used: CC=clang CXX=clang++ cmake <path to compiler-rt> -DLLVM_CONFIG_PATH=<Path to llvm toolchain>/bin/llvm-config -DCOMPILER_RT_INSTALL_PATH=<Path to llvm toolchain>/lib/clang/3.7.0 after this command on console it prints, -- Compiler-RT supported architectures: x86_64 Instead if I use gcc in above

Hi Timo: You need to find LLVMConfig.cmake in the binary or install directory tree, not the source tree. Although I don't embed clang/llvm, my config might help you figure it -- clang/llvm installed under (could have used build directory) ~/usr : $ cd /Users/dhinton/projects/cover/build/ && rm -rf * && CC=~/usr/bin/clang CXX=~/usr/bin/clang++ LLVM_DIR=~/usr/lib/cmake/llvm

Hi; I have a very basic question about reading element from dataframe T (2 dimentional) I want to extract element T[1,1] as a string. T[1,1] returns an element with "names", means header. this i cannot compare with any other list of strings. how can i fix that? Thanks Rami _________________________________________________________________ [[alternative HTML version

Hi; I have a very basic question about reading element from dataframe T (2 dimentional) I want to extract element T[1,1] as a string. T[1,1] returns an element with "names", means header. this i cannot compare with any other list of strings. how can i fix that? Thanks Rami _________________________________________________________________ Get back to school stuff for them and

Sorry my example wasn't helpful. I did take a quick look at rust -- though I didn't download or try to build it -- and they seem to allow you to use an installed or prebuilt version in addition to building it in-tree. However, even when they build it in-tree, they build the whole thing -- see mk/llvm.mk. Good luck... On Mon, Oct 10, 2016 at 1:33 AM, Timo Janssen via llvm-dev <

I need to build libLLVM (individual static libraries are fine at the moment) using mingw-w64 cross compilers, i686-w64-mingw32-gcc and (separately) x86_64-w64-mingw32-gcc. I'd like this to work from both Linux and Cygwin build environments. With autotools, this worked fine: ../configure --host=i686-w64-mingw32 and that's it (with mingw32-gcc-c++ installed on Fedora 23, also works fine on

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

I am trying to compile llvm using a toolchain file where I have specified the target system and compilers as suggested at https://cmake.org/cmake/help/latest/manual/cmake-toolchains.7.html#cross-compilation-tool chain: set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-unknown-linux-gnueabi-gcc) set(CMAKE_CXX_COMPILER arm-unknown-linux-gnueabi-g++) But the

The behavior of automatically detecting libraries installed in the same prefix feels like magic to me anyway. Perhaps it would be better to have project-level variables for specifying the path to them individually? The default value for them could remain as origin/../lib which would keep from breaking things. On Thu May 29 2014 at 7:06:17 PM, Chandler Carruth <chandlerc at google.com>

Hi all. I want to use llvm in my project and I want to make llvm a git submodule in my project. http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project At this in the documentation it claims to describe how to embed llvm into a project. I tried it that way but it doesn't work, because there isn't any findLLVM.cmake in the llvm/cmake/modules directory anymore (i don't

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

This way, an LLVM compiled after setting GCC_INSTALL_PREFIX will work correctly if you don't want to install LLVM into the GCC_INSTALL_PREFIX. --- CMakeLists.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index 9ec3e33..c85a028 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -450,7 +450,12 @@ if (APPLE)

I think the simplest fix is something like this: diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp index c6f0d17f8fe..e81957ab80a 100644 --- a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp +++ b/lib/Transforms/Instrumentation/SanitizerCoverage.cpp @@ -256,6 +256,7 @@ SanitizerCoverageModule::CreateSecStartEnd(Module

The CrossCompile module is in a perpetual state of "when I get a chance...", and desperately needs some cleanup. The problem you are hitting is caused by setting CMAKE_SYSTEM_NAME. When you set that CMake sets a variable CMAKE_CROSS_COMPILING. That variable should only be set when your host OS doesn't match your target OS. Since LLVM needs to build host-capable tools there is some

On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <mail at justinbogner.com> > wrote: > >> I think the simplest fix is something like this: >> >> diff --git a/lib/Transforms/Instrumentation/SanitizerCoverage.cpp >>

On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org> wrote: > >> On 9 Feb 2018, at 10:20, Hans Wennborg <hans at chromium.org> wrote: ... >> What are all these test failures? Does it seems like they have a >> common root cause and do we have a bug for it? ... > The Clang Tools and Extra Tools Unit tests all appear to crash with: >

Hi Brad, I have a few questions regarding ExternalProject_Add. For me it doesn't really work as expected. I add the following code to the tools/clang/runtime/CMakeLists.txt to configure compiler-rt as external project: ExternalProject_Add(compiler-rt #DEPENDS clang clang++ llvm-config PREFIX ${CMAKE_BINARY_DIR}/projects/compiler-rt SOURCE_DIR ${COMPILER_RT_SRC_ROOT}

Hello, LLVM community. I've built a cross-toolchain on Windows and I'm now trying to run unit tests for the LLVM libraries. I used Ninja as a build system and MSVC as host compiler without an issue, but when I try to run 'ninja check-llvm-unit', I get the following error: llvm-lit.py: C:/Users/sergej/Developer/llvm-project/llvm\utils\lit\lit\TestingConfig.py:102: fatal: unable