similar to: Strange clang behavior when compiled against musl

Hello there, I'm building a Linux distribution based on musl and LLVM as default toolchain (including lld/libc++/libc++abi/libunwind rather than GNU). For most of the time this works pretty well. However I'm having troubles with few packages, webkit for instance fails because of max_align_t being redeclared in musl's stddef.h I see that stddef.h is provided by both musl and in the

Hello, I'm trying to create a pure LLVM toolchain (that will not depend on GNU and produce GNU-free code too) on a musl based distribution. For now, I use gcc to bootstrap and build all LLVM components. I do it individually because I was running out of space and memory trying to build all using LLVM_ENABLE_PROJECTS. Also, I don't want to create a all-in-one package. Then, once

I tree to compile the LLVM ORC JIT examples. But I'm stuck in some problems I can't solve my own. First at all I compile with C++14 enabled with latest stable LLVM and clang, this means 4.0.1. I get the following error. Do I missed some specific compile option? Compilation looks like this here. |CompilingcontribJIT.cpp PWD:/home/ikuehl/projects-llvm/TurboLisp/domainEngineer

Hi, I am trying to compare the loop vectorizers effectiveness for different targets relative to each other. That way, I am hoping to find loops that are not vectorized - but could be - on my target by finding other targets doing this successfully. With some luck, there might be something in the Target files that could be fixed with improved vectorization as a result... I would like to do

On Fri, Mar 4, 2016 at 5:50 PM, Yuanfeng Peng <yuanfeng.jack.peng at gmail.com> wrote: > Hi Jingyue, > > My name is Yuanfeng Peng, I'm a PhD student at UPenn. I'm sorry to bother > you, but I'm having trouble with gpucc in my project, and I would be really > grateful for your help! > > Currently we're trying to instrument CUDA code using LLVM 3.9, and

Hi, Yuanfeng. What version of clang are you using? CUDA is only known to work at tip of head, so you must build clang yourself from source. I suspect that's your problem, but if building from source doesn't fix it, please attach the output of compiling with -v. Regards, -Justin On Sun, Jul 31, 2016 at 9:24 PM, Chandler Carruth <chandlerc at google.com> wrote: > Directly

Hi Justin, Thanks for your response! The clang & llvm I'm using was built from source. Below is the output of compiling with -v. Any suggestions would be appreciated! *clang version 3.9.0 (trunk 270145) (llvm/trunk 270133)* *Target: x86_64-unknown-linux-gnu* *Thread model: posix* *InstalledDir: /usr/local/bin* *Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8*

You are right. Thanks! I fixed that one as well as some other issues. I built LLVM-8 with Debug + no-rtti. But it now has the following error: Stack dump: 0. Program arguments: clang-8 -cc1 -triple x86_64-unknown-linux-gnu -emit-llvm -disable-free -main-file-name time-1.7.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases

OK, I see the problem. You were right that we weren't picking up libdevice. CUDA 7.0 only ships with the following libdevice binaries (found /path/to/cuda/nvvm/libdevice): libdevice.compute_20.10.bc libdevice.compute_30.10.bc libdevice.compute_35.10.bc If you ask for sm_50 with cuda 7.0, clang can't find a matching libdevice binary, and it will apparently silently give up and try to

Hi, Can someone who's familiar with lld take a look? [2980/3371] Building C object tools/llvm-c-test/CMakeFiles/llvm-c-test.dir/disassemble.c.o [2981/3371] Building CXX object tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o FAILED: tools/lld/COFF/CMakeFiles/lldCOFF.dir/Writer.cpp.o /opt/arm/arm-linux-compiler-20.0_Generic-AArch64_RHEL-7_aarch64-linux/bin/armclang++ -DGTEST_HAS_RTTI=0

While attempting to reduce a ubsan-specific bug, I stumbled upon the following. [I would have filed a bug report, but don't have an account, and so requested one per https://bugs.llvm.org/ about 7 hours ago -- but still no response, so am sending this instead. ] Using clang built from latest master of about 5 hours ago: $ echo struct a typename a | clang -x c++ - <stdin>:1:19: error:

Hello, I am building the SPEC 2006 Benchmark with Clang as the compiler. I have written a function pass in LLVM and I am trying to run that for SPEC by invoking the pass in the build options of SPEC. The build options of SPEC are in a *.cfg config file, which allows us to specify the choice of compiler while building SPEC. (https://www.spec.org/cpu2006/Docs/install-guide-unix.html) The pass

Hmm. Odd. I just rebuilt from scratch and it seems to work with the test/CodeGen/X86/xray-attribute-instrumentation.ll test case outputing straight to obj: llc -filetype=obj -o ~/a.o -mtriple=x86_64-apple-macosx < test/CodeGen/X86/xray-attribute-instrumentation.ll What test case are you using? In any case, the issue appears to be that llvm doesn't realize that the target address is

Hi Alexey, I submitted the bug report to nvidia. While they are working on it, can you share some insight in what could potentially cause this? I just want to get a sense if such a bug require significant amount of work to fix, which can help me make some decision moving forward with my project. Thanks, Char At 2019-02-27 03:19:02, "Alexey Bataev" <a.bataev at outlook.com>

Thanks Nirav, I can confirm that this works when I do the compile with llc, but then when linking to an executable with clang (patched with http://reviews.llvm.org/D20352 and compiler-rt patched with http://reviews.llvm.org/D21612) on Linux, I'm getting something different. Here's a sample of the transcript, and what I'm seeing: --->8 clang invocation 8<--- [16-06-23 3:33:42]

Hi Tim, Thanks for your suggestion! I built LLVM with Debug and tried this with my custom pass. But it has the following error error: unable to load plugin '../../trace-extractor/build/TracePass.so': '../../trace-extractor/build/TracePass.so: undefined symbol: _ZTIN4llvm10ModulePassE’ Originally I used a builtin Clang in the system and it does not produce this issue. When I search

Hi Alexey, Just want to make sure I understand what you said because I'm not familiar with the llvm pipeline, it's this line: /net/gs/vol3/software/modules-sw/cuda/10.0/Linux/RHEL6/x86_64/bin/ptxas" -m64 -g --dont-merge-basicblocks --return-at-end -v --gpu-name sm_75 --output-file /tmp/60663577.1.login.q/testparticles-4fd988.o /tmp/60663577.1.login.q/testparticles-1d20c4.s that

On Wed, Jun 22, 2016 at 6:05 AM Nirav Davé <niravd at google.com> wrote: > This appears to work: > > auto Target = OutContext.createLinkerPrivateTempSymbol(); > > with > > auto Target = OutContext.createTempSymbol(); > > -Nirav > > Thanks Nirav -- I tried this but I'm still getting a "jmpq <address>" with this incantation when I load and

Dear sir, Thanks for your reply. I apologize for taking a few days to reply. > Crashed how? Please see the below. > Have you turned on ASan? Not yet, but thanks for the suggestion. I guess I will try to rebuild my modified Clang+LLVM with addr. san. and see what happens. > I recommend attaching a minimal reproduction... Well, since I`m hacking on LLVM itself, this is not

Hi, On the OpenMandriva side, x86_64 passes all checks. We're having some problems with other architectures though (see below): x86_64 succeeded, packages are here: https://abf.openmandriva.org/build_lists/76792 i586 fails to build, but this seems to be an issue with 3.8.1 (which we're using to build 3.9): /usr/bin/clang++ -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS