Unfortunately I still can't reproduce this even using exactly the same cmake command as you gave. Looking at above cmake log some possible causes of difference are:

• I'm doing this on an M1 macbook with host triple arm64-apple-darwin21.6.0 but the host triple on that bot is x86_64-apple-darwin20.6.0
• I'm using python 3.9, bot is using python 3.10
• I'm doing a build from clean whereas the bot is doing an incremental build

In D136675#4213750, @vigneshv wrote:

Please let me know if you need any more details. :)

In D144651#4210787, @fdeazeve wrote:

According to git-bisect, this patch is causing the LLDB bots to crash.
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/52690/console

(They were failing for other reasons before, which is why it took a while for this to be identified)

Clang is crashing with: Assertion failed: (0 && "Invalid SLocOffset or bad function choice"

In particular, this is true for the test lldb-api :: commands/expression/import_builtin_fileid/TestImportBuiltinFileID.py
I'm currently investigating the other failures reported by the bot, but we've also seen this assert fire internally in some other flows.

Remove only the generated tests, use -Wno-deprecated elsewhere.

LGTM, with one minor nitpick.

Ping.

Changed to removing testing of the ext/* headers.

D145691 should fix the libc++ CI failures.

Add command line test and release note, and run clang-format.

Ran clang-format.

In D144654#4156430, @aaron.ballman wrote:

This seems to cause precommit CI failures that should be addressed, and it should also have a release note about the fix.

Failures in CI should be fixed by D145397 and D144651. I'll also add a release note.

Fixed a couple of things causing failures in clangd tests (path being prepended in front of <command line>, and a bit of code assuming that command-line macros were builtin).

I noticed that llvm-nm has slightly different output for undefined symbols to GNU nm: GNU nm doesn't list value and size, llvm-nm list value and size zero. I've pushed a fix for that in https://reviews.llvm.org/rGe5d914672233, which may possibly also fix the AIX failure if AIX nm behaves in a similar way to llvm-nm.

I could reproduce the failure in PluginInlineAdvisorTest.PluginLoad to find _ZN4llvm13AllAnalysesOnINS_6ModuleEE6SetKeyE on Linux as well, when using a suitable build configuration. Fixed in
https://reviews.llvm.org/rG78f13ea093afdebcaa3b5c5690530b9217bbdfac on Linux, and hopefully also on AIX. I don't expect it to fix the failure to find _ZN4llvm15SmallVectorBaseIjE13mallocForGrowEPvmmRm though, so I'll try to figure out what's going on there also.

In D142989#4115843, @Jake-Egan wrote:

Hi, this caused some failures on AIX, could you take a look?

Adjusted summary, removed superfluous \.

In D142989#4095488, @glandium wrote:

Could you add before/after figures of the numbers of symbols in, say, clang.symbols in the summary?

LGTM

It looks like if MSVC is implementing sequentially-consistent atomic operations in the manner described then we will need to stores (but not loads) in the same way, so it looks like this patch is doing the right thing. Reasoning below:

Looking at GCC it looks like there (for cortex-m0 at least) the behaviour is that loads and stores are generated inline, but more complex operations go to the atomic library calls (not the sync library calls). e.g. for

Ping.

Rebased again.

In D137155#3899932, @plotfi wrote:

LGTM, Nice work John.

Would format_hex_no_prefix be replaceable with std::format once C++20 for LLVM drops?

Adjusted to find physical register uses and defs by iterating through all operands, as the defs list doesn't include implicit defs. Added a test based on the code in ffmpeg that was getting incorrectly optimised.

I've reverted. Looks like there's something going on with a flags-setting SUBS being hosted above a conditional branch.

Rebased. Also adjust invalidateWindowsRegisterPairing to use encoded register numbers which should be more robust.

In D133199#3769823, @labrinea wrote:

the expansion of cttz to a table

Can you explain what that means?

LGTM

Looking at the descriptions of maths functions in C99 (and I expect C11 will be the same) it looks like there are three kinds:

• Those that can report error by errno and floating-point exeption, and may also raise the inexact exception
• Those that don't set errno, but may raise the inexact exception
• Those that neither set errno or raise an exception

LGTM.

LGTM.

Also check for sys/wait.h, and rename the feature to has-unix-headers.

Looks good, I'll commit this for you.

In D122959#3475470, @ZhiyaoMa98 wrote:

I would like to add a test, but I do not know how. My understanding is that I will need to create an example that PrologueMBB has non-immediate predecessors. Is there any example I can follow? Thanks!

After doing some more experimentation I don't think it's possible to get this to work in all cases. If we make a copy of the closure then any containers in it will be copied, but copies of iterators will still point to the container outside of the closure copy, and this causes a bunch of tests to fail.

In D124255#3470538, @ldionne wrote:

This looks really interesting! However, doesn't that mean that we can't assert that the process terminates if a certain condition is met?

Also adjust aarch64-v8.2a-fp16-intrinsics-constrained.c in this patch (was previously done in
D115620) and remove the checks of the generated asm.

Removed clang test changes.

Ping.