similar to: [LLVMdev] LLD dynamic compilation

On 30 June 2014 16:16, Shankar Easwaran <shankare at codeaurora.org> wrote: > I think you are hitting a bug, the Observer pattern was added a few weeks > back, and may be there is some sort of uninitialized variable ? This is my back-trace at "-O2 -g" (since -O1 pass): operator() (file=<optimized out>, __closure=0x7fffffffde40) at

> Run it through its phases and report any bugs you find! [ 1495s] CMake Warning (dev) at projects/dragonegg/CMakeLists.txt:34 (get_target_property): [ 1495s] Policy CMP0026 is not set: Disallow use of the LOCATION target property. [ 1495s] Run "cmake --help-policy CMP0026" for policy details. Use the cmake_policy [ 1495s] command to set the policy and suppress this warning. [

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 12:55:20 PM > Subject: Re: lld and thread over-subscription > >

On Thu, Oct 1, 2015 at 10:55 AM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I honestly think that the ulimit of 1024 max threads is too strict for 48 > core machine. Processes are independent each other, so it is not strange > for them to spawn as many threads as the number of cores. What's the reason > you cannot increase the limit? > Yeah, this is

----- Original Message ----- > From: "Rui Ueyama" <ruiu at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers" <llvm-dev at lists.llvm.org>, "Rafael Espindola" <rafael.espindola at gmail.com> > Sent: Thursday, October 1, 2015 11:46:05 AM > Subject: Re: lld and thread over-subscription > >

On Tue, Jan 20, 2015 at 6:06 PM, Rui Ueyama <ruiu at google.com> wrote: > On Tue, Jan 20, 2015 at 5:42 PM, Chandler Carruth <chandlerc at google.com> > wrote: > >> >> On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: >> >>> On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> >>>

Hi Rui, et al., I was experimenting yesterday with building lld on my POWER7 PPC64/Linux machine, and ran into an unfortunate problem. When running the regressions tests under lit, almost all of the tests fail like this: terminate called after throwing an instance of 'std::system_error' what(): Resource temporarily unavailable ... 5 libc.so.6 0x00000080b7847238 abort +

I'm seeing some test failures for unit tests for msan (check-msan) happening in googletest, which I find weird. I'm on Arch Linux, with r342711. Below is one type of error that I see. The full log is 416MB (!) big. My guess is that those errors are related, but if anyone needs the full log, I'll provide it. Here is a reduced log from the end:

We are modeling target specific functionally using references, Doesn't your idea defeat the purpose of the atom model? Atoms are mostly target neutral and yaml/native format represents just an atom. Having a derived class for atoms will have a impact on the testing method with lld IMO. We could continue to model using references in my opinion and add some meta data information in the atom

Hi, I'm hitting that issue since Mesa 20.0.6 and it is present still in latest version 20.1.7 ``` [tkloczko at barrel SPECS]$ coredumpctl gdb 3926866 PID: 3926866 (test_va_api) UID: 1000 (tkloczko) GID: 1000 (tkloczko) Signal: 11 (SEGV) Timestamp: Sun 2020-09-13 18:57:06 BST (32s ago) Command Line: ./test_va_api Executable:

On Tue, Jan 20, 2015 at 5:35 PM, Nick Kledzik <kledzik at apple.com> wrote: > On Jan 19, 2015, at 6:33 PM, Chandler Carruth <chandlerc at google.com> > wrote: > > > I wanted to go through and map out the layering of LLD's libraries today > and found that it's essentially impossible. I think some serious cleanup is > needed here. > > > >

I am nuilding that now. CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=$HOME/opt/llvm11-git \ -DCMAKE_BUILD_TYPE=Release \ -DBUILD_SHARED_LIBS=ON \ -DLLVM_ENABLE_EH=ON \ -DLLVM_ENABLE_RTTI=ON \ -DLLVM_HOST_TRIPLE=x86_64-pc-linux-gnu \ -DLLVM_TARGETS_TO_BUILD="AMDGPU;MSP430;WebAssembly;X86" \

Do you really need to build the C library for MLIR? If so, it looks like it's just a missing dependency - MPFR library. Or if you do have that library available, it's missing expected features. On Thu, Apr 23, 2020 at 12:29 PM Luke A. Guest via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Here's the error: > > [1921/7570] /usr/lib/llvm/10/bin/clang++

Hello, Since 2.5 is near, I have been trying to build llvm and llvm-gcc for MingW, but hit several problem (using the current trunk). First issue is that unittests don't build for MingW, the attached patch should fix it. Second issue is that llvm-gcc fails for me with the following error: /c/cygwin/home/jlerouge/buildbot/llvm-test/gcc-build/./gcc/xgcc

Hi, Have anybody recently built LLVM in Debug mode /within/ space requirements from the Getting Started doc? https://llvm.org/docs/GettingStarted.html#hardware > An LLVM-only build will need about 1-3 GB of space. A full build of LLVM and Clang will need around 15-20 GB of disk space. From my experience this numbers looks drastically low. On FreeBSD my recent builds consumed more than

Hi, I try to build lldb with Cmake (gcc-5.3.0 is necessary for CUDA) on my "SUSE Linux Enterprise Server 12.2 (x86_64)". Unfortunately the build process breaks for lldb with the below mentioned error message. I've downloaded the following packages and configured with the following commands. svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm/tools svn co