ping

Added static_asserts that check that SourceRange and SourceLocation are trivially destructible.

I will wait until the end of this week to see if anyone has objections.

This revision was landed with ongoing or failed builds.

Refactored SLocEntry in a similar way.

Abandoning in favor of D94237 and D94596.

In D94237#2493844, @dblaikie wrote:

Do you need to run the destructor before placement new in these situations?

Fixed a typo in the word "implicit"

Removed alignas

Fixed formatting.

Hi @MaskRay, this commit broke our builds which use GCC 7.3. I've posted some comments in D92591, but have just realized that it probably was not the right place. Could you please fix the breakage?

I guess I'll leave it in our downstream version then.

Fixed linter errors.

Reverted the accidentally removed chunk.

Addressed review comments

In D69903#2340020, @dexonsmith wrote:

An alternative would be to update the unions to an AlignedCharArrayUnion and use SourceLocation directly. WDYT?

The test failure is unrelated (see D89463)

Added an example of usage.

Split out the refactoring part.

Yes, I am still interested in working on this. For now, I've split out some changes that don't require any modifications in SourceLocation into https://reviews.llvm.org/D89705.

A general comment is that there are a couple of functional changes in this patch, where hash values are changing and data structures are being changed, but they're buried in the noise of the refactoring that's going on at the same time. I suggest splitting this up at least into two

Will do.

Customization allows storing data of OS structures such as mutexes and threads in-place, thus avoiding the need for additional dynamic memory allocations, this is important in embedded environments.

Given this new setup where build bots are checked into the repo, I think adding a bot that test this configuration would be a good way of making sure this doesn't regress. What do you think?

Yes, setting up a build bot is part of my original plan. I will be on holiday for the next two weeks, but I do plan to continue working on this after returning.

Is there a reason why your platform can't simply provide the pthread or the C11 threading APIs, and libc++ has to provide this bridge instead?

The original intent of the external threading API was to make it usable with bare-metal real-time OS-es which tend not to have POSIX or POSIX-like APIs. For example, __libcpp_mutex_t can include the OS structure representing a mutex, instead of allocating it elsewhere.

@ldionne, do you have any thoughts on how we might progress this forward?

Use setenv in the parent process

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