In our case, the child process fails to find the correct version of libstdc++ and exits with return code 1, ASSERT_EQ(-2, RetCode) fails.

Thanks!

Hi Olivier,
Prior versions of the C++ standard (11, 14, 17) required more specialized templates for atomic_fetch_{add,sub}[_explicit] for pointers. E.g.:

template <class T>
T atomic_fetch_add(atomic<T>*, T) noexcept;
template <class T>
T* atomic_fetch_add(atomic<T*>*, ptrdiff_t) noexcept;

Implementing them as a single template breaks the following code (when compiled as C++17):

#include <atomic>

I've just committed D86773

Thanks!

Small refactoring of bitcode updater tests (use some-name.ll.bc names for bitcode files in order to be able to refer to them as %s.bc from some-name.ll)

Sorry about that. I've reverted the change and will investigate.

1. Also update bfdot
2. Add auto-upgrade for old intrinsics

Cast to the correct type

Abandoning in favour of:

1. Addressed review comments
2. Added a cast back to the original type

Keep the second vbfmlaltq_laneq_f32 test

In D86146#2226702, @dmgreen wrote:

Do we need to upgrade the old bfmmla to the new signatures?

For intrinsics that are plain functions (not macros) you could just check the signatures using assignments to function pointers, e.g.:

The mangling agrees with https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
LGTM

I have reproduced the type 1 failure and I confirm that this patch fixes the issue.

LGTM. Please wait until Friday before committing, so that others have a chance to share their objections.

Addressed the review comments

1. Rebased and fixed failures
2. Added a test for AArch64 codegen of lane copying intrinsics
3. Addressed reviewers' comments

Workaround the dependency of bf16 on fullfp16

Rebased. Added a workaround for bf16 arguments and returns (lowering currently works only with +fullfp16).

In D81559#2085031, @ldionne wrote:

In D81559#2085002, @miscco wrote:

Do we need to reenable the test somewhere?

My understanding is that it was never disabled, it just started failing with a recent compiler. @miyuki is that correct?

• Addressed reviewer's comments
• Rebased on top of a patch which implements the correct calling convention for returning bfloat values

Returns look wrong, but they should be fixed in the calling convention patch

Fixed the "RUN:" line in the A32 test, implemented vduph_lane for A32.

LGTM

Addressed reviewers' comments.

I'm curious to understand what your setup is.

Internally we use _LIBCPP_HAS_THREAD_API_EXTERNAL in our downstream libc++ fork intended for the bare-metal environment. We aim to provide testing of this configuration and also the _LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL one. The plan is to set up public build bots for testing them. Unfortunately, this work is not high-priority, so I cannot make any commitments w.r.t. to it.

David is working with me on improving the testing of external threading configurations.

The updated patch LGTM