done the load or who need the oldStatus information after adding the
status record.
Change some of the memory barrier logic since we can take advantage of
load-through HW address dependency.
Radar-Id: rdar://problem/105634683
The threading implementations need to include Impl.h, not just their
specific variant, to pick up the `stack_bounds` type.
Also fix a newly exposed problem with Atomic.h.
rdar://90776105
The threading implementations need to include Impl.h, not just their
specific variant, to pick up the `stack_bounds` type.
Also fix a newly exposed problem with Atomic.h.
rdar://90776105
The placement new operator is only available when `<new>` has been
included. Add the missing include to the header to allow us to get the
definition of the placement new allocator. This allows us to remove the
workaround that was there for Windows, and should hopefully repair the
Android build as well.
Thanks to @grynspan for helping identify the underlying issue!
Not all targets have a 16-byte type alignment guarantee. For the types
which are not naturally aligned, provide a type specific `operator new`
overload to ensure that we are properly aligning the type on allocation
as we run the risk of under-aligned allocations otherwise.
This should no longer be needed with C++17 and newer which do a two
phase `operator new` lookup preferring
`operator new(std::size, std::align_val_t)` if needed. The base type
would be fully pre-processed away. The empty base class optimization
should help ensure that we do not pay any extra size costs for the
alignment fixes.
As we are a C++14 codebase, we must locally implement some of the
standard type_traits utilities, namely `void_t`. We take the minimal
definition here, assuming that the compiler is up-to-date with C++14 DR
reports which fixed an issue in SFINAE. We use the SFINAE for detecting
the presence of the `operator new` overload to guide the over-alignment,
which is inherited through the new `swift::overaligned_type<>` base
type.
Annotate the known classes which request explicit alignment which is
non-pointer alignment. This list was identified by
`git grep ' alignas(.*) '`.
The `AllocationPool` type is reflected upon and inspected by debugging
tools. This requires that the layout of the atomically wrapped type
must store the value at offset 0. However, the `std::atomic` does not
make any such guarantees, and a layout differing would render debug
utilities useless. Switch instead from a `std::atomic` to
`swift::atomic`. In order to do so, we also need to introduce the
`compare_exchange_strong` helper which maps to
`compare_exchange_strong_explicit` mirroring `compare_exchange_weak`.
We would previously include a header inside the `swift::impl` namespace,
which would prevent the proper declaration of the functions and
enumerators. This corrects the location of the header inclusion to fix
this issue.
Credit for the cmake fix here goes to Saleem Abdulrasool.
The substantive fix is embarrassing; I didn't pay close attention
to the intrinsic's argument order and just assumed that the first
argument for the replacement value was the low half (the part
you'd find at index 0 if it were an array), but in fact it's the
high half (the part you'd find at index 1).
I also change the code to be much more reinterpret_casty, which
isolates the type-punning mostly "within" the intrinsic, and
which seems to match how other code uses it.
Update the instances of checks for architectures to be more broad for different
spellings of the architecture macro. Certain targets use `_M_ARM` and others
use `__arm__`. Similarly, arm64/aarch64 has `_M_ARM64`, `__arm64__` and
`__aarch64__` as spellings. This just mechanically goes through and encodes the
various spellings.
Take the opportunity to replace some raw checks with `defined` checks which
avoids a pedantic warning due to the undefined macro when performing the check
as the preprocessor may warn about an undefined condition evaluating to `0`.
