Page MenuHomePhabricator
Feed Advanced Search

Today

phosek reopened D45639: [Driver] Support default libc++ library location on Darwin.
Fri, Apr 23, 12:20 AM · Restricted Project

Yesterday

phosek added a reverting change for rG6331680ad2ad: Re-land "[Driver] Support default libc++ library location on Darwin": rGd5f433d3302e: Revert "Re-land "[Driver] Support default libc++ library location on Darwin"".
Thu, Apr 22, 2:04 PM
phosek committed rGd5f433d3302e: Revert "Re-land "[Driver] Support default libc++ library location on Darwin"" (authored by phosek).
Revert "Re-land "[Driver] Support default libc++ library location on Darwin""
Thu, Apr 22, 2:04 PM
phosek added a comment to D100232: [Coverage] Support overriding compilation directory.

Can you add a test case for the llvm-cov new flag? Otherwise looks good to me.

Thu, Apr 22, 12:12 PM · Restricted Project
phosek added a comment to D100535: [llvm-cov] Support for v4 format in convert-for-testing.

@phosek I apologize for the delay in reviewing this.

Thanks for doing this. I've done a few passes over the logic changes and think they look fine. I think the only thing that's missing is a .covmapping test blob to test the new v4 support.

Thu, Apr 22, 11:56 AM · Restricted Project
phosek updated the diff for D100232: [Coverage] Support overriding compilation directory.
Thu, Apr 22, 11:55 AM · Restricted Project
phosek committed rG45340efb4c7d: [Driver] Specify -ccc-install-dir for linux-cross test (authored by phosek).
[Driver] Specify -ccc-install-dir for linux-cross test
Thu, Apr 22, 10:58 AM
phosek closed D101023: [Driver] Specify -ccc-install-dir for linux-cross test.
Thu, Apr 22, 10:58 AM · Restricted Project
phosek updated the diff for D101023: [Driver] Specify -ccc-install-dir for linux-cross test.
Thu, Apr 22, 10:57 AM · Restricted Project
phosek updated the diff for D101023: [Driver] Specify -ccc-install-dir for linux-cross test.
Thu, Apr 22, 10:42 AM · Restricted Project
phosek requested review of D101023: [Driver] Specify -ccc-install-dir for linux-cross test.
Thu, Apr 22, 12:11 AM · Restricted Project

Wed, Apr 21

phosek committed rGf749550cfe9f: [libcxx] Stop using use c++ subdirectory for libc++ library (authored by phosek).
[libcxx] Stop using use c++ subdirectory for libc++ library
Wed, Apr 21, 3:39 PM
phosek closed D100869: [libcxx] Stop using use c++ subdirectory for libc++ library.
Wed, Apr 21, 3:39 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek abandoned D88843: [libcxx] Don't treat Windows specially with visibility annotations.

I don't think we need this anymore.

Wed, Apr 21, 3:09 PM · Restricted Project
phosek committed rG7a718e163023: [MC] Use COMDAT for LSDA only if IR comdat type is any (authored by phosek).
[MC] Use COMDAT for LSDA only if IR comdat type is any
Wed, Apr 21, 2:42 PM
phosek closed D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.
Wed, Apr 21, 2:41 PM · Restricted Project
phosek added inline comments to D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.
Wed, Apr 21, 11:20 AM · Restricted Project
phosek updated the diff for D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.
Wed, Apr 21, 11:19 AM · Restricted Project
phosek added a comment to D45639: [Driver] Support default libc++ library location on Darwin.

This breaks TestAppleSimulatorOSType.py on GreenDragon. First failed build: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/31346/
[...]

Based on your description above, shouldn't it prefer the libc++ form the sysroot?

Actually, it's the other way around. In the discussion above, we say it's the toolchain path first, then anything provided with -L, and then the sysroot. Here you have a dylib in the toolchain root (assuming that's what jenkins/workspace/lldb-cmake/lldb-build is), so it's using that. It seems that the library built in the toolchain root is built for x68_64 (probably your host), whereas you'd need it to be built for the target (i386 simulator).

Wed, Apr 21, 10:57 AM · Restricted Project

Tue, Apr 20

phosek added a comment to D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.

Test?

Tue, Apr 20, 11:54 PM · Restricted Project
phosek updated the diff for D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.
Tue, Apr 20, 11:54 PM · Restricted Project
phosek added inline comments to D100907: [lsan][docs] Clarify supported platforms.
Tue, Apr 20, 4:32 PM · Restricted Project
phosek requested review of D100909: [MC] Use COMDAT for LSDA only if IR comdat type is any.
Tue, Apr 20, 4:17 PM · Restricted Project
phosek added a comment to D45639: [Driver] Support default libc++ library location on Darwin.

Another attempt is rGcaff17e503fe.

Tue, Apr 20, 1:46 PM · Restricted Project
phosek committed rGcaff17e503fe: [Driver] Don't use capture for InstalledDir (authored by phosek).
[Driver] Don't use capture for InstalledDir
Tue, Apr 20, 1:44 PM
phosek added a comment to D45639: [Driver] Support default libc++ library location on Darwin.

Looks like this breaks tests on windows: http://45.33.8.238/win/37191/step_7.txt

Tue, Apr 20, 1:31 PM · Restricted Project
phosek committed rGf5efe0aa048b: [Driver] Support both slashes (authored by phosek).
[Driver] Support both slashes
Tue, Apr 20, 1:26 PM
phosek committed rGae8b2cab6740: [Driver] Support default libc++ library location on Darwin (authored by phosek).
[Driver] Support default libc++ library location on Darwin
Tue, Apr 20, 12:30 PM
phosek closed D45639: [Driver] Support default libc++ library location on Darwin.
Tue, Apr 20, 12:30 PM · Restricted Project
phosek requested review of D100869: [libcxx] Stop using use c++ subdirectory for libc++ library.
Tue, Apr 20, 10:22 AM · Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek accepted D100711: [ORC-RT] Initial ORC Runtime directories and build system files..

LGTM

Tue, Apr 20, 1:10 AM · Restricted Project

Mon, Apr 19

phosek added a comment to D100535: [llvm-cov] Support for v4 format in convert-for-testing.

Ping?

Mon, Apr 19, 10:02 AM · Restricted Project

Fri, Apr 16

phosek added a comment to D99381: [compiler-rt][hwasan] Add Fuchsia-specific sanitizer platform limits.

I see, it's exposed here https://github.com/llvm/llvm-project/blob/6d2d3bd0a61f5fc7fd9f61f48bc30e9ca77cc619/compiler-rt/include/sanitizer/hwasan_interface.h#L88.

Fri, Apr 16, 12:54 PM · Restricted Project
phosek added a comment to D100631: [libc] Extends the testing framework to support typed test.

I'll check with zxtest maintainers.

Fri, Apr 16, 12:11 PM · Restricted Project
phosek added a comment to D100631: [libc] Extends the testing framework to support typed test.

I'll check with zxtest maintainers.

Fri, Apr 16, 11:52 AM · Restricted Project
phosek added a reviewer for D100631: [libc] Extends the testing framework to support typed test: mcgrathr.
Fri, Apr 16, 11:51 AM · Restricted Project

Thu, Apr 15

phosek committed rG9ac988f6a80a: [libcxx] Make the GDB pretty printer test less strict (authored by phosek).
[libcxx] Make the GDB pretty printer test less strict
Thu, Apr 15, 11:34 PM
phosek closed D99532: [libcxx] Make the GDB pretty printer test less strict.
Thu, Apr 15, 11:34 PM · Restricted Project
phosek added a comment to D45639: [Driver] Support default libc++ library location on Darwin.

Just following up on this, cos I'm curious :) I have 12.1 now, and I still only see the C++ headers in the toolchain and not in any of the SDKs.

Look in Xcode 12.5 beta 3, you should see libc++ headers in the SDK. You'll also see headers alongside Clang, however those are not being used. They are just there for some internal reasons but eventually we'll have only one copy of the headers, and they'll be in the SDK.

As I explained in https://reviews.llvm.org/D45639#2360267, I think this is the right way forward. We want LLVM Clang to prefer the libc++.dylib (and headers) shipped in the toolchain if those are present, since that's the most consistent approach.

Just one question: with this patch, do we prefer the library in the SDK or the one in the toolchain if both are present? Can we get into trouble if we have both paths on the -L list? I'm trying to think of subtle issues like:

<toolchain>/lib/libc++.a
<sysroot>/lib/libc++.dylib

Which one would we pick here?

Thu, Apr 15, 10:39 PM · Restricted Project
phosek added a comment to D100535: [llvm-cov] Support for v4 format in convert-for-testing.

I ran into this issue when trying to create a test for D100232.

Thu, Apr 15, 1:25 AM · Restricted Project
phosek requested review of D100535: [llvm-cov] Support for v4 format in convert-for-testing.
Thu, Apr 15, 1:24 AM · Restricted Project

Tue, Apr 13

phosek added a comment to D89013: [libcxx] Support per-target __config_site in per-target runtime build.

@ldionne friendly ping.

Tue, Apr 13, 1:36 PM · Restricted Project, Restricted Project
phosek updated the diff for D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Tue, Apr 13, 8:36 AM · Restricted Project, Restricted Project

Mon, Apr 12

phosek accepted D99992: [mlgo] Skip AOT-compiling a model if a header/object pair is provided.

LGTM

Mon, Apr 12, 9:20 PM · Restricted Project
phosek added a comment to D99532: [libcxx] Make the GDB pretty printer test less strict.

@ldionne @curdeius friendly ping?

Mon, Apr 12, 5:08 PM · Restricted Project

Fri, Apr 9

phosek updated the diff for D100232: [Coverage] Support overriding compilation directory.
Fri, Apr 9, 3:34 PM · Restricted Project
phosek updated the diff for D100232: [Coverage] Support overriding compilation directory.
Fri, Apr 9, 2:33 PM · Restricted Project
phosek requested review of D100232: [Coverage] Support overriding compilation directory.
Fri, Apr 9, 2:32 PM · Restricted Project
phosek added inline comments to D100054: Handle flags such as -m32 when computing the prefix for programs/runtime libs.
Fri, Apr 9, 10:54 AM · Restricted Project

Thu, Apr 8

phosek accepted D99368: [compiler-rt][hwasan] Add C++17 new/delete operators with alignment.

LGTM but you should wait a bit for @pcc or @eugenis to have a chance to to review this as well.

Thu, Apr 8, 2:19 PM · Restricted Project

Tue, Apr 6

phosek added a reverting change for rG849d3729433e: [NFC][Clang] Speculative fix for builtins-ppc-quadword-noi128.c: rG000cf84cf1bb: Revert "[NFC][Clang] Speculative fix for builtins-ppc-quadword-noi128.c".
Tue, Apr 6, 11:23 PM
phosek committed rG000cf84cf1bb: Revert "[NFC][Clang] Speculative fix for builtins-ppc-quadword-noi128.c" (authored by phosek).
Revert "[NFC][Clang] Speculative fix for builtins-ppc-quadword-noi128.c"
Tue, Apr 6, 11:23 PM
phosek added a reverting change for rG31d219d2997f: [InstCombine] Fold `((X - Y) - Z)` to `X - (Y + Z)` (PR49858): rGa547b4e26b31: Revert "[InstCombine] Fold `((X - Y) - Z)` to `X - (Y + Z)` (PR49858)".
Tue, Apr 6, 10:46 PM
phosek committed rGa547b4e26b31: Revert "[InstCombine] Fold `((X - Y) - Z)` to `X - (Y + Z)` (PR49858)" (authored by phosek).
Revert "[InstCombine] Fold `((X - Y) - Z)` to `X - (Y + Z)` (PR49858)"
Tue, Apr 6, 10:46 PM
phosek added a comment to rG31d219d2997f: [InstCombine] Fold `((X - Y) - Z)` to `X - (Y + Z)` (PR49858).

After this change, we're seeing Clang stuck in what appears to be an infinite loop when compiling the XRay runtime. The failing compiler invocation is:

/src/clang-llvm/llvm-build/fuchsia/./bin/clang++ --target=x86_64-unknown-linux-gnu -DXRAY_HAS_EXCEPTIONS=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/src/clang-llvm/llvm-project/compiler-rt/lib/xray/.. -I/src/clang-llvm/llvm-project/compiler-rt/lib/xray/../../include --target=x86_64-unknown-linux-gnu -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections -no-canonical-prefixes -Wall -std=c++14 -Wno-unused-parameter -O2 -g -DNDEBUG -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 -gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -fno-rtti -MD -MT compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o -MF compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o.d -o compiler-rt/lib/xray/CMakeFiles/RTXray.x86_64.dir/xray_x86_64.cpp.o -c /src/clang-llvm/llvm-project/compiler-rt/lib/xray/xray_x86_64.cpp
Tue, Apr 6, 10:29 PM
phosek added a comment to D89013: [libcxx] Support per-target __config_site in per-target runtime build.

@ldionne any more thoughts on this?

Tue, Apr 6, 4:19 PM · Restricted Project, Restricted Project
phosek accepted D99621: [CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`..

LGTM (I've tested this together with D99621 locally for the Fuchsia build and everything seems to be working).

Tue, Apr 6, 12:34 AM · Restricted Project
phosek added a comment to D99621: [CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`..

Thanks, this seems to work fine in my setups now!

When building via llvm/runtimes (which I don't use so I don't have a test setup handy), I believe that sets TARGET_TRIPLE somehow. Does that end up trying to probe the triple from the compiler in that case? I guess it'd always be correct, but if we'd avoid the whole probing in that case too, that'd be great. Maybe it already does that - or the runtimes build does thing differently somehow? (I've just tried to read llvm/runtimes/CMakeLists.txt.) Or maybe we end up in a case where these routines aren't called at all in such a build?

I might be able to try to set up such a build configuration in a couple days to try that out though...

I'm not sure. Reading that code is a little confusing...

So there are external project invocations that pass

  1. LLVM_DEFAULT_TARGET_TRIPLE. That looks like it's only used in compiler-rt to help with finding GNU gold/ld. So that probably doesn't matter here.
  2. TARGET_TRIPLE as an argument to the llvm_ExternalProject_Add() function

The second one is a bit confusing.

There's this code inside llvm_ExternalProject_Add

if(NOT ARG_TARGET_TRIPLE)
  set(target_triple ${LLVM_DEFAULT_TARGET_TRIPLE})
else()
  set(target_triple ${ARG_TARGET_TRIPLE})
endif()

is_msvc_triple(is_msvc_target ${target_triple})

but then target_triple doesn't get used again... which makes no sense. (@phosek @beanz is this a bug?).

Tue, Apr 6, 12:33 AM · Restricted Project
phosek accepted D99620: [CMake][Compiler-rt] Compute LLVM_MAIN_SRC_DIR assuming the monorepo layout..

LGTM (I've tested this together with D99621 locally for the Fuchsia build and everything seems to be working).

Tue, Apr 6, 12:31 AM · Restricted Project
phosek added a comment to D99860: Remove `COMPILER_RT_INSTALL_PATH`.

I'm worried that overriding CMAKE_INSTALL_PREFIX is going to break the runtimes build where we build compiler-rt, libcxx, libcxxabi, libunwind in a single CMake build, and compiler-rt always comes first see https://github.com/llvm/llvm-project/blob/98742e42fc50f58d3f2d3f2cdbbf540288c134b9/runtimes/CMakeLists.txt#L57.

Tue, Apr 6, 12:09 AM · Restricted Project, Restricted Project
phosek added a comment to D99810: [ifs] Prepare llvm-ifs for elfabi/ifs merging..

This change is pretty large so I'm wondering if we could possibly split it into two changes, one that does the purely mechanical renaming of ELF and TBE to IFS, and second one that merges the two tools?

Tue, Apr 6, 12:07 AM · Restricted Project, Restricted Project

Fri, Apr 2

phosek added a comment to D99695: [llvm-cov] Use -path-equivalence to support relative path..
In D99695#2664701, @vsk wrote:

I think then you would somehow need multiple -compilation-dir options if e.g. you have paths with different levels of ../ nesting, e.g. ../../foo.c and ../../../../bar.c. That sounds like it could become hard to manage.

In RawCoverageFilenamesReader::readUncompressed, we do:

SmallString<256> P(CWD);
llvm::sys::path::append(P, Filename);

Can this just be turned into an absolute path?

The flag would override the compilation dir that's stored inside the profile (the 0th path entry) so there should be just one. In that code snippet, it means overriding CWD.

That makes sense.
Do we need a new flag or just use -path-equivalence like this patch?

Fri, Apr 2, 5:39 PM · Restricted Project
phosek added a comment to D98926: [sanitizer] Simplify GetTls with dl_iterate_phdr on Linux and use it on musl/FreeBSD.

After this change, we're also seeing a leak being reported in BoringSSL when running on Debian 9 (stretch) which appears to be a false positive, see fxbug.dev/73487 for more details.

Fri, Apr 2, 5:38 PM · Restricted Project
phosek added a comment to D89013: [libcxx] Support per-target __config_site in per-target runtime build.

@ldionne I have update the change description to explain the new layout.

Fri, Apr 2, 12:34 PM · Restricted Project, Restricted Project
phosek updated the summary of D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Fri, Apr 2, 12:33 PM · Restricted Project, Restricted Project

Thu, Apr 1

phosek added a comment to D99706: [CMake] Include dependency on cxx-headers in compiler-rt tests.
Thu, Apr 1, 8:32 PM · Restricted Project
phosek committed rGb0d286b03c6e: [CMake] Use append instead of set with the list (authored by phosek).
[CMake] Use append instead of set with the list
Thu, Apr 1, 8:31 PM
phosek added a comment to D99755: Remove `clang/runtime`.

@beanz do you know if clang/runtime is still being used?

Thu, Apr 1, 2:00 PM · Restricted Project, Restricted Project, Restricted Project
phosek added reviewers for D99755: Remove `clang/runtime`: beanz, phosek.
Thu, Apr 1, 2:00 PM · Restricted Project, Restricted Project, Restricted Project
phosek added a comment to D99695: [llvm-cov] Use -path-equivalence to support relative path..
In D99695#2664701, @vsk wrote:

I think then you would somehow need multiple -compilation-dir options if e.g. you have paths with different levels of ../ nesting, e.g. ../../foo.c and ../../../../bar.c. That sounds like it could become hard to manage.

In RawCoverageFilenamesReader::readUncompressed, we do:

SmallString<256> P(CWD);
llvm::sys::path::append(P, Filename);

Can this just be turned into an absolute path?

Thu, Apr 1, 11:37 AM · Restricted Project
phosek added a comment to D99695: [llvm-cov] Use -path-equivalence to support relative path..

We ran into this issue as well where the compilation directory is set to . and path starts with ../.. (we use similar setup to Chromium) so llvm-cov tries to write files outside of the coverage directory. The way to address it I was considering would be to provide a way to override compilation directory, for example llvm-cov show --compilation-dir=/path/to/source/out/default ... so if the path stored in profile is ../../a/b.c, then it'd become /path/to/source/a/b.c. This would address the issue for us but I'm not sure if it's the best possible solution. What do you think?

Thu, Apr 1, 10:54 AM · Restricted Project
phosek committed rG775e55462a64: [CMake] Include dependency on cxx-headers in compiler-rt tests (authored by phosek).
[CMake] Include dependency on cxx-headers in compiler-rt tests
Thu, Apr 1, 10:42 AM
phosek closed D99706: [CMake] Include dependency on cxx-headers in compiler-rt tests.
Thu, Apr 1, 10:42 AM · Restricted Project
phosek updated the diff for D99706: [CMake] Include dependency on cxx-headers in compiler-rt tests.
Thu, Apr 1, 10:39 AM · Restricted Project
phosek committed rG96d8c6b571e6: [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX (authored by phosek).
[CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX
Thu, Apr 1, 10:13 AM
phosek closed D99697: [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX.
Thu, Apr 1, 10:13 AM · Restricted Project, Restricted Project, Restricted Project
phosek added inline comments to D99706: [CMake] Include dependency on cxx-headers in compiler-rt tests.
Thu, Apr 1, 10:08 AM · Restricted Project

Wed, Mar 31

phosek added a comment to D97572: [libc++] Include <__config_site> from <__config>.

We're seeing two test failures on macOS in bootstrap builds after this: https://bugs.chromium.org/p/chromium/issues/detail?id=1194745

Wed, Mar 31, 11:26 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek requested review of D99706: [CMake] Include dependency on cxx-headers in compiler-rt tests.
Wed, Mar 31, 11:26 PM · Restricted Project
phosek added a comment to D99697: [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX.

Oh there is a stray LIBCXX_INSTALL_HEADER_PREFIX in LIBCXX_INSTALL_HEADER_PREFIX that should be removed, FYI.

Wed, Mar 31, 10:41 PM · Restricted Project, Restricted Project, Restricted Project
phosek updated the diff for D99697: [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX.
Wed, Mar 31, 10:40 PM · Restricted Project, Restricted Project, Restricted Project
phosek added inline comments to D99484: Use `GNUInstallDirs` to support custom installation dirs..
Wed, Mar 31, 5:58 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek added inline comments to D99484: Use `GNUInstallDirs` to support custom installation dirs..
Wed, Mar 31, 5:45 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek requested review of D99697: [CMake] Remove {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_PREFIX.
Wed, Mar 31, 5:44 PM · Restricted Project, Restricted Project, Restricted Project
phosek added inline comments to D99484: Use `GNUInstallDirs` to support custom installation dirs..
Wed, Mar 31, 5:17 PM · Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project, Restricted Project
phosek added inline comments to D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Wed, Mar 31, 3:25 PM · Restricted Project, Restricted Project
phosek added a comment to D89013: [libcxx] Support per-target __config_site in per-target runtime build.

I'm personally not so concerned with the Clang driver side of things, but primarily with adding more complexity to the libc++ build. Shouldn't we be driving things from the runtimes build and setting a different CMAKE_INSTALL_PREFIX to install stuff to the right location instead? Then you can run N builds of libc++ for N targets, each setting the appropriate install path.

Wed, Mar 31, 3:22 PM · Restricted Project, Restricted Project
phosek updated the diff for D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Wed, Mar 31, 3:12 PM · Restricted Project, Restricted Project
phosek added a comment to D89013: [libcxx] Support per-target __config_site in per-target runtime build.

Regarding

/usr/include/x86_64-unknown-linux-gnu/c++/v1
/usr/include/c++/v1

With GCC multiarch, some include search paths are preceded by machine-os-env specific suffix directories.
Note: 'vendor' is not there. So you may see .../include/x86_64-linux-gnu but there is no .../include/x86_64-{pc,unknown}-linux-gnu

/usr/local/include/x86_64-linux-gnu         # affected by sysroot, multiarch, usually nonexistent
/usr/local/include                          # affected by sysroot
/tmp/opt/gcc-debug/include
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed
/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include
/usr/include/x86_64-linux-gnu               # affected by sysroot, multiarch
/usr/include                                # affected by sysroot

On Debian x86_64, /usr/include/x86_64-linux-gnu/ exists. Adding x86_64-pc-linux-gnu (an possible value of LLVM_DEFAULT_TARGET_TRIPLE) may add more confusion.

Wed, Mar 31, 12:30 PM · Restricted Project, Restricted Project
phosek updated the diff for D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Wed, Mar 31, 12:05 PM · Restricted Project, Restricted Project
phosek committed rGfcf680050686: [Driver] Move detectLibcxxIncludePath to ToolChain (authored by phosek).
[Driver] Move detectLibcxxIncludePath to ToolChain
Wed, Mar 31, 10:51 AM
phosek closed D88452: [Driver] Move detectLibcxxIncludePath to ToolChain.
Wed, Mar 31, 10:51 AM · Restricted Project

Tue, Mar 30

phosek updated the diff for D89013: [libcxx] Support per-target __config_site in per-target runtime build.
Tue, Mar 30, 7:05 PM · Restricted Project, Restricted Project
phosek added a comment to D99620: [CMake][Compiler-rt] Compute LLVM_MAIN_SRC_DIR assuming the monorepo layout..

The biggest issue with the current setup is that compiler-rt build relies on various LLVM build artifacts, like using the just built Clang but not in a very disciplined way which requires us to use various workaround like this: https://github.com/llvm/llvm-project/blob/99fd0662278470f5405b8abd79b681b96cac7856/runtimes/CMakeLists.txt#L116 (if you search for compiler-rt in that file, you'll see other issues).

Tue, Mar 30, 6:17 PM · Restricted Project
phosek added inline comments to D99399: [elfabi] Prepare llvm-elfabi for elfabi/ifs merging..
Tue, Mar 30, 5:47 PM · Restricted Project
phosek updated the diff for D88452: [Driver] Move detectLibcxxIncludePath to ToolChain.
Tue, Mar 30, 4:10 PM · Restricted Project
phosek updated the diff for D89013: [libcxx] Support per-target __config_site in per-target runtime build.

@ldionne this is ready for review now that D97572 landed.

Tue, Mar 30, 3:50 PM · Restricted Project, Restricted Project
phosek abandoned D83911: [libcxx] Move the libc++ header paths to the common location.

Combined into D89013.

Tue, Mar 30, 3:30 PM · Restricted Project
phosek added a comment to D99621: [CMake][Compiler-rt] Make it possible to configure standalone compiler-rt without `LLVMConfig.cmake`..

Do you know what we need LLVMConfig.cmake for? Could we remove that dependency altogether? It's not used by any other runtime as far as I'm aware.

I wouldn't want to remove the dependency at this stage as not enough of this new code has been tested (I only tested on macOS). However, I think this patch could used as a stepping stone towards completely removing the dependency on LLVMConfig.cmake. If we landed this and did the necessary work to make this new code path work on all the host platforms we care about then I think we could remove the dependency on LLVMConfig.cmake. I'd like to see that happen because the requirement makes testing harder and seems unnecessary.

Tue, Mar 30, 3:07 PM · Restricted Project
phosek added a comment to D99620: [CMake][Compiler-rt] Compute LLVM_MAIN_SRC_DIR assuming the monorepo layout..

Other runtimes like libc++, libc++abi and libunwind already assume the monorepo layout and don't rely on llvm-config. Removing the llvm-config dependency would allow further cleanups in the compiler-rt build so this is a highly desirable change. Given that, I'd actually prefer just making this the default behavior.

Tue, Mar 30, 2:45 PM · Restricted Project