- User Since
- Aug 19 2016, 10:21 AM (242 w, 1 d)
Tue, Apr 6
Unless you think it only makes sense when paired with the rest of this diff, could you split out the renaming of SubsectionMapping to SubsectionMap into its own NFC diff (and probably just commit that directly)? It'd make the rest of this diff easier to read.
Sun, Apr 4
Thu, Apr 1
Wed, Mar 31
Tue, Mar 30
Thu, Mar 25
Wed, Mar 24
Tue, Mar 23
Sat, Mar 20
Got it, thanks for all the info!
Fri, Mar 19
With NDK r22, I only see libunwind.a for armv7. Will it be provided for other architectures in future NDK versions?
Tue, Mar 16
Sounds good. I'll let Fangrui take a look then :)
The summary says !isLocal but the code says !isLazy. I'm assuming the code is correct.
Mon, Mar 15
Mar 11 2021
Mar 10 2021
This will already work as-is for the runtimes build (since it builds the builtins standalone), but builtins-config-ix already sets an equivalent option for compiler-rt's custom macros, so it should be fine to apply this one universally to the builtins as well (either in this file or in builtins-config-ix).
Hilariously enough, this breaks building compiler-rt itself inside LLVM's runtime builds setup for us. The runtimes build setup builds clang and then uses the just-built clang to build compiler-rt. That build fails to link since my just-built clang doesn't have compiler-rt available, because it's currently trying to build compiler-rt itself. That's a bug in the compiler-rt build system, and I sent out https://lists.llvm.org/pipermail/llvm-dev/2021-March/149137.html to ask what we should do about it.
Mar 9 2021
Mar 5 2021
Mar 4 2021
Address review comments
Mar 3 2021
Mar 2 2021
Sorry for the delay here. This looks good; thank you!
I suppose it's more efficient to have a single iteration of the argument list, but I also don't think argument parsing efficiency matters at all (or at least doesn't matter enough for this change to be a problem), so LGTM.
If you care about eventually getting rid of the old check-clang-tools alias, you'd want to have a mailing list announcement/deprecation notices/etc. (I don't think leaving it around does any harm though.)
Is this rebased on main? The LLD for Mach-O changes look like they belong to a different diff.
Mar 1 2021
Feb 26 2021
Feb 24 2021
Feb 22 2021
LGTM. Do you have commit access?
My understanding of the issue is that, with the runtimes build, the cxx target will get created after we process LLDB's build files. The TARGET cxx check here will therefore fail, but the cxx target will end up existing later, and CMake is perfectly fine adding a dependency to a target that gets created later, so the failing check is spurious. The libcxx IN_LIST LLVM_ENABLE_RUNTIMES is basically a proxy for "the cxx target doesn't exist right now but will exist later". Could you add an explanation of the issue to the summary or the code comment?
Feb 19 2021
Feb 16 2021
Will this fix https://bugs.llvm.org/show_bug.cgi?id=17550?
Feb 11 2021
Adding some reviewers who've contributed to the SHA1 implementation.
Feb 10 2021
The NATIVE build is also used for cross-compilation scenarios (e.g. you're building on Windows but targeting Linux, but you still need tools like tablegen to be built targeting Windows), and for those cases, using the same CMAKE_TOOLCHAIN_FILE as the main build is completely incorrect.
Feb 8 2021
It works! Thanks @mehdi_amini
Feb 7 2021
Feb 5 2021
Feb 3 2021
A few other cases that might be good to have test cases for as well, but I'll let you judge that:
- Empty (and non-empty) archive members
- Empty (and non-empty) universal binary members, possibly with and without -arch_only
Should we warn on files that would have been filtered out by -arch_only? (What does cctools libtool do?)
Feb 2 2021
Feb 1 2021
I saw this on LLVM Weekly, and I like it a lot :)
I'm also confused how the ALWAYS_GENERATE name related to its actual functionality ... might have been something historic?
Jan 22 2021
Jan 19 2021
We've been pretty liberal with our use of option groups, mostly to organize the help text. I agree that the commit message should reflect that there's some new version options being added as well (tvos, watchos, bridgeos, and driverkit, if I'm reading the diff right).
Jan 12 2021
Running the unit test with ASAN gives me the following. The stack trace isn't the most helpful, unfortunately, but it should hopefully be something to go on.
It's been a long time since I've contributed to libc++, and the pre-merge CI setup is a massive improvement over what we had before. A huge kudos to everyone who made it possible :)
Thanks, I committed this. You might get some buildbot failure emails. Given the nature of this change, they're overwhelmingly likely to be false positives, but feel free to forward them to me if you want confirmation. (Search for me in LLVM's git log to get my email.)
Jan 11 2021
@compnerd is already part of the libc++abi group, but I'm also adding him explicitly in case he has the time to look, since he has a lot of relevant experience.
Sorry, I seem to have somehow blanked out on this diff entirely. Is it still relevant?