sanitizer_common_interceptors.inc:667:12: warning: address of function 'memchr' will always evaluate to 'true' [-Wpointer-bool-conversion]
if (REAL(memchr)) {
~~ ^~~~~~
llvm-svn: 276539
Otherwhise undefined references to symbols defined in linker scripts
are never resolved.
Differential Revision: https://reviews.llvm.org/D22664
llvm-svn: 276536
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
This unblocks the new PM part of River's patch in
https://reviews.llvm.org/D22706
Conveniently, this same change was needed for D21921 and so these
changes are just spun out from there.
llvm-svn: 276515
Additionally, for pre-C++1z, instead of forbidding a lambda's closure type from being a literal type through circumlocutorily setting HasNonLiteralTypeFieldsOrBases falsely to true -- handle lambda's more directly in CXXRecordDecl::isLiteral().
One additional small step towards implementing constexpr-lambdas.
Thanks to Richard Smith for his review!
https://reviews.llvm.org/D22662
llvm-svn: 276514
This is the first patch in the coroutine series.
It contains the documentation for the coroutine intrinsics and their usage.
Patch by Gor Nishanov!
Differential Revision: https://reviews.llvm.org/D22603
llvm-svn: 276513
While we handed loads past the end of an array, we didn't handle loads
_before_ the array.
This fixes PR28062.
N.B. While the bug in the code is obvious, I am struggling to craft a
test case which is reasonable in size.
llvm-svn: 276510
struct a bit bigger under MSVC (this shouldn't be a big deal; we typically
allocate no more than two of these at a time, on the stack).
llvm-svn: 276509
There is a bug in Clang 3.6 and earlier that causes compile failures.
I suspect it's due to the usage of member function parameter names in the
attributes.
llvm-svn: 276507
Summary:
This patch uses the __attribute__((enable_if)) hack suggested by @rsmith to diagnose invalid arguments when possible.
In order to diagnose an invalid argument `m` to `f(m)` we provide an additional overload of `f` that is only enabled when `m` is invalid. When that function is enabled it uses __attribute__((unavailable)) to produce a diagnostic message.
Reviewers: mclow.lists, rsmith, jfb, EricWF
Subscribers: bcraig, jfb, rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D22557
llvm-svn: 276506
This change lets us prove things like
"{X,+,10} s< 5000" implies "{X+7,+,10} does not sign overflow"
It does this by replacing replacing getConstantDifference by
computeConstantDifference (which is smarter) in
isImpliedCondOperandsViaRanges.
llvm-svn: 276505
It's been pointed out that arbitrarily spraying raw profiles into a
build directory is insane. Doing this wastes a tremendous amount of
space and is also very lossy, since the test harness tends to wipe away
temporary sub-directories (which usually contain relevant profile data).
The new default is a `profiles` directory inside of the build dir.
llvm-svn: 276504
Tobias Grosser