Due to some unfortunate interplay between clang and libstdc++, clang was
not able to correctly identify to alignment of PoolRange and
SideTableRefCountBits, causing it to emit library calls instead of
inlining atomic operations. This was fixed by adding the appropriate
alignment to those types. In addition to that the march for the Linux
target was set to 'core2', which is the earliest architecture to support
cx16, which is necessary for the atomic operations on PoolRange.
Use the C++ spelling for the static assertions. This is a C11
extension, but GCC and MSVC both object to the reserved spelling
(`_Static_assert`). Use the compatibility spelling of `static_assert`
on all targets instead.
`RefCount.h` can be included in a C context - e.g. building the
SwiftShims module. Restrict the C++ overloads to the C++ context only.
This partially improves the build for Windows ARM64.
Unfortunately, `std::atomic` in msvcprt as of 14.21.27702 is broken for
double-width atomics on ARM64. This has been reported to Microsoft and
is going to be fixed in VC++ 2019u3. For the time being, add a partial
template specialisation for the two double-word sized types temporarily
as a workaround. This allows the standard library build to get further.
The assertions here are based around the idea that `std::atomic` is
trivially constructible which is not a guarantee that the standard fully
provides. The default initialization of the `std::atomic` type may
leave it in an undetermined state. These were caught using the Visual
C++ preview runtime.
Ideally, the object constructor would use a placement new operator.
However, prior to C++17, the C++ standard mandated that there be a
NULL pointer check in the placement new operator. This is something
which is no longer the case with C++17. Switch to the placement new
operator for C++17 and newer and enable that codepath for Windows as
well (which seemingly elides the null-pointer check with clang-cl).
Rather than directly using the extension `__builtin_expect`, use a macro
to permit the removal of the builtin on compilers which do not support
this (i.e. cl). This permits us to build the swift compiler with MSVC
again.
The Allocations Instrument overrides swift_retain with a function that records the retain count by calling swift_retainCount. Its assert for bits.getIsDeiniting() is incorrect in that case, so remove it.
The recent change to ObjC tagged pointer bits on x86-64 also caused the various bridgeObjectRetain/Release functions to call through to swift_retain for BridgeObject tagged values on Mac. swift_retain ignored those values so there was no functional change, except when Instruments overrode it and passed them to swift_retainCount, which tried to dereference them and crashed. Modify bridgeObjectRetain/Release to bail out early again. Also modify swift_retainCount to ignore those values in case anything else expects retainCount to work on any pointer swift_retain accepts.
rdar://problem/45102538
The SwiftStdint.h header is used in the compiler as well. The compiler may be
built with cl (Visual Studio) on Windows, which does not define
`__INTPTR_TYPE__` nor does it define `__INTPTR_WIDTH__`. Simply define the
`__swift_{,u}intptr_t` typedefs as Microsoft does on that platform when building
with Visual Studio.
Given any heap object, this method dumps:
* The pointer address of the heap object.
* The pointer address of the heap metadata of the object.
* The strong reference count.
* The unowned reference count.
* The weak reference count.
* Whether or not the value is in the deinit state.
* Whether or not the heap object uses swift_retain or objc_retain.
* The address of the object's side table if one exists.
This makes it really easy when debugging quickly to get all of the information
that you could possibly need from a HeapObject.
32-bit has a 7-bit inline unowned refcount, then 31 bits in the side table. Overflowing the inline count in deinit on an object that didn't already have a side table would crash, because the code assumed that creating a side table in deinit was not allowed.
(64-bit has 31 bits inline and in the side table. Overflowing the inline count immediately overflows the side table as well, so there's no change in behavior there.)
rdar://problem/33765960
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
* Check for overflow in incrementWeak().
This mirrors what is currently done for unowned reference counts, where overflowing the side table field produces a fatal error. Without this, the count silently wrapped from 2^31-1 to 0, which then caused breakage when the balancing releases happened (possibly including use-after-free bugs).
* Fix the implementation of RefCounts::getWeakCount().
The previous implementation was only appropriate for heap objects, but not side tables. This resulted in the weak count always returning 0 or 1. This change specializes the implementation for the two different cases and returns the correct count for side tables.
* Test large weak retain counts.
This tests the largest allowed weak retain count, as well as the overflow check when that count is exceeded.
(instead of an unused field that we'd rather not initialize)
constexpr can't be 100% enforced in a template, so instead it gets
silently dropped if the instantiated function doesn't fulfill all the
requirements of being constexpr. In this case, that was a constructor
not explicitly initializing all fields, even the one we marked
unavailable. This meant we were using a non-constexpr constructor to
instantiate a global, which semantically requires static
initialization.
(The actual initialization is still optimized away at the LLVM
level. But the Clang frontend doesn't know that.)
Note that the warning will still fire unless you update your Clang
build; I just today cherry-picked the change that handles unnamed
bitfields correctly.
This is a blanket pass replacing use of `__LP64__` with
`__POINTER_WIDTH__ == 64`. The latter is more expressive and also LLP64
clean. This change is needed to enable support for Windows x86_64 which
is a LLP64 environment.
On 32bit platforms there are 7 bits reserved for the unowned retain count. This
makes overflow a likely scenario. Implement overflow into the side table.
rdar://33495003
HeapObject contains an InlineRefCounts. The Swift shim definition of
InlineRefCounts used uint64_t, which has the correct size but the incorrect
alignment on armv7k. This caused the Swift stdlib and the Swift runtime
to disagree about object layouts.
rdar://31664545
This is a purely mechanical change replacing the attributes with the reserved
spelling. Compilers are to not error when they encounter a reserved spelling
for an attribute which they do not support.
It's to be used by code produced by the ReleaseDevirtualizer.
As the function is only used for non-escaping objects, the deallocating bit is set non-atomically.
