similar to: Bootstrapping with in-tree libcxx

On Tue, Dec 27, 2016 at 1:29 PM, Carsten Mattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > When I tried to build with -DLLVM_ENABLE_LIBCXX, I found out that > it doesn't try to use the in-tree libcxx but looks for one built and > installed > in the system. > IIRC, -DLLVM_ENABLE_LIBCXX reduces to passing --stdlib=libc++ (see [1]) to the compiler. What you can

On Tue, Dec 27, 2016 at 3:38 PM, Asiri Rathnayake <asiri.rathnayake at gmail.com> wrote: > > > On Tue, Dec 27, 2016 at 1:29 PM, Carsten Mattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> When I tried to build with -DLLVM_ENABLE_LIBCXX, I found out that >> it doesn't try to use the in-tree libcxx but looks for one built >> and

On Tue, Dec 27, 2016 at 2:45 PM, Carsten Mattner <carstenmattner at gmail.com> wrote: > On Tue, Dec 27, 2016 at 3:38 PM, Asiri Rathnayake > <asiri.rathnayake at gmail.com> wrote: > > > > > > On Tue, Dec 27, 2016 at 1:29 PM, Carsten Mattner via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > >> > >> When I tried to build with

If you're willing to install libc++ you can easily work around this by running `ninja install-cxx install-cxxabi` before running any of the LLVM or Clang build targets. /Eric On Tue, Dec 27, 2016 at 7:45 AM, Carsten Mattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Tue, Dec 27, 2016 at 3:38 PM, Asiri Rathnayake > <asiri.rathnayake at gmail.com> wrote: >

Hi All, libcxx is fairly well designed to work in a no-exceptions environment, with most of the sources diligently using the _LIBCPP_NO_EXCEPTIONS macro. However, it seems to have bit-rotted a bit and could use some TLC right now. A no-exceptions variety of libcxx would be quite useful when you want to use all of libcxx goodness without the overhead of exceptions (especially in embedded

Greetings! I have been building llvm-3.6.x, 3.7.1 and 3.7.2 with (glibc-2.12.1, binutils-2.24, gcc-4.9.2) almost same set if CMake flags. However while building LLVM-3.8.0 using same CMake flags I am observing projects/libcxx/include/cmath errors... ...'::signbit' has not been declared ...'::fpclassify' has not been declared ...'::isfinite' has not been declared ...

cmake -E cmake_progress_report llvm-3.8.0.src_bld_x86_64-rhel6.4-linux-gnu/CMakeFiles In file included from llvm-3.8.0.src/projects/libcxx/include/__hash_table:19:0, from llvm-3.8.0.src/projects/libcxx/src/hash.cpp:10: llvm-3.8.0.src/projects/libcxx/include/cmath:310:9: error: '::signbit' has not been declared using ::signbit; ^

I just landed these patches: commit c55051eea5d3cd57abfd9727f519b670517704d9 Author: Louis Dionne <ldionne at apple.com> Date: Thu Jun 25 12:02:43 2020 -0400 [libunwind] Allow specifying custom Lit config files This is the libunwind counterpart of 0c66af970c80. commit 33c9c10d183371edc95fa936705bef56f55ab611 Author: Louis Dionne <ldionne at

> I find it amusing that you think that there's a "correct behavior" when the standard specifies > that an operation should throw an exception and you have disabled exceptions. You got me there! I think it's OK to be consistent across all the places and call abort(), this is what I've been doing in my current patch. I will double check this behavior with other

I try to compile LLVM, clang, lld and libcxx together in one source directory following the instructions on the website. I'm running Arch Linux and already have LLVM, clang, lld and libcxx installed (prebuilt against libstdc++). Now I want a "pure" llvm toolchain. The following options were used: -DBOOTSTRAP_LLVM_ENABLE_LLD -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++

You also need -DLIBUNWIND_USE_COMPILER_RT=ON -DLIBCXXABI_USE_LLVM_UNWINDER=ON. This is because you set -DLIBCXXABI_USE_COMPILER_RT=ON so libc++abi.so is no longer being linked agains libgcc_s.so which is where the unwinder otherwise comes from. On Sun, May 6, 2018 at 4:05 AM via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I try to compile LLVM, clang, lld and libcxx together in one

Posting to the list first, rather than filing a bug because I'm not sure this is still an intended configuration: With LLVM configured as: CXX=clang++ CC=clang cmake ../llvm/ \ -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_INSTALL_PREFIX=~/install/llvm-master/ \ -DLLVM_TARGETS_TO_BUILD=host \ -DLLVM_ENABLE_ASSERTIONS=true \ -DLLVM_ENABLE_LIBCXX=yes \ -DLLVM_ENABLE_LIBCXXABI=yes The check-all target

On 9 Feb 2018, at 22:30, Dimitry Andric <dimitry at andric.com> wrote: > > On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <openmp-dev at lists.llvm.org> wrote: >> >> 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>

On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> > wrote: > > > > well, top-of-branch lldb uses this code, that's how I found it. Do you > mean libc++'s demangler? > > Thanks for explaining, this is the first time

On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <openmp-dev at lists.llvm.org> wrote: > > 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 >>>

I think it may make sense to segregate the libcxx lit tests that expect a task to be completed in a particular threshold. Either they should move to the llvm test-suite or they should be under a feature guard that omits them from the default test target. These tests are sensitive to the load and/or capability of the target on which they're tested. I appreciate that it's likely

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

On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake < asiri.rathnayake at gmail.com> wrote: > > > On Tue, Apr 25, 2017 at 8:36 PM, Vedant Kumar via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> >> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> >> wrote: >> > >> > well, top-of-branch lldb

On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 9 Feb 2018, at 22:30, Dimitry Andric <dimitry at andric.com> wrote: >> >> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev <openmp-dev at lists.llvm.org> wrote: >>> >>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev <cfe-dev at lists.llvm.org>

Thank you. > On Jul 3, 2019, at 4:04 AM, Justin Clift <justin at postgresql.org> wrote: > > On 2019-07-01 00:22, Marty Itzkowitz via llvm-dev wrote: >> I also tried spack install llvm at develop on a POWER9 (ppc641e) >> machine, but I can not find a compiler that >> will compile it. gcc 4.8.5 is reported as too old, and gcc 7.3.0 and >> 8.1.0 both fail in