Revert "[ubsan] Reduce null checking of C++ object pointers (PR27581)"

This reverts commit r295391. It breaks this bot:

http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/1898

I n

Revert "[ubsan] Reduce null checking of C++ object pointers (PR27581)"

This reverts commit r295391. It breaks this bot:

http://lab.llvm.org:8011/builders/clang-with-thin-lto-ubuntu/builds/1898

I need to not rely on labels in the IR test.

llvm-svn: 295396

show more ...

[ubsan] Reduce null checking of C++ object pointers (PR27581)

This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.

Previously, given a load of a membe

[ubsan] Reduce null checking of C++ object pointers (PR27581)

This patch teaches ubsan to insert exactly one null check for the 'this'
pointer per method/lambda.

Previously, given a load of a member variable from an instance method
('this->x'), ubsan would insert a null check for 'this', and another
null check for '&this->x', before allowing the load to occur.

Similarly, given a call to a method from another method bound to the
same instance ('this->foo()'), ubsan would a redundant null check for
'this'. There is also a redundant null check in the case where the
object pointer is a reference ('Ref.foo()').

This patch teaches ubsan to remove the redundant null checks identified
above.

Testing: check-clang and check-ubsan. I also compiled X86FastISel.cpp
with -fsanitize=null using patched/unpatched clangs based on r293572.
Here are the number of null checks emitted:

-------------------------------------
| Setup | # of null checks |
-------------------------------------
| unpatched, -O0 | 21767 |
| patched, -O0 | 10758 |
-------------------------------------

Differential Revision: https://reviews.llvm.org/D29530

llvm-svn: 295391

show more ...

[ubsan] Minimize size of data for type_mismatch (Redo of D19667)

Summary:
This patch makes the type_mismatch static data 7 bytes smaller (and it
ends up being 16 bytes smaller due to alignment restr

[ubsan] Minimize size of data for type_mismatch (Redo of D19667)

Summary:
This patch makes the type_mismatch static data 7 bytes smaller (and it
ends up being 16 bytes smaller due to alignment restrictions, at least
on some x86-64 environments).

It revs up the type_mismatch handler version since we're breaking binary
compatibility. I will soon post a patch for the compiler-rt side.

Reviewers: rsmith, kcc, vitalybuka, pgousseau, gbedwell

Subscribers: llvm-commits

Differential Revision: https://reviews.llvm.org/D28242

llvm-svn: 291236

show more ...

Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."

Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers:

Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."

Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171

Reviewers: djasper, Anastasia

Subscribers: yaxunl, cfe-commits, bader

Differential Revision: https://reviews.llvm.org/D27981

llvm-svn: 290431

show more ...

CodeGen: ubsan is built static on windows, give handlers local storage

The UBSAN runtime is built static on Windows. This requires that we give local
storage always. This impacts Windows where the

CodeGen: ubsan is built static on windows, give handlers local storage

The UBSAN runtime is built static on Windows. This requires that we give local
storage always. This impacts Windows where the linker would otherwise have to
generate a thunk to access the symbol via the IAT. This should repair the
windows clang build bots.

llvm-svn: 289829

show more ...

CodeGen: clean up -Wpedantic warning (NFC)

lib/CodeGen/CGExpr.cpp:2511:2: warning: extra ';' [-Wpedantic]
};
^

Clean up warning from gcc 6.

llvm-svn: 289514

Avoid use of std::to_string. NFC.

Apparently this routine isn't available on some Android platforms. See
the mailing list thread re: D21695.

llvm-svn: 289452

[Fix] Add missing include from r289444.

llvm-svn: 289446

[clang] Version support for UBSan handlers

This adds a way for us to version any UBSan handler by itself.
The patch overrides D21289 for a better implementation (we're able to
rev up a single handle

[clang] Version support for UBSan handlers

This adds a way for us to version any UBSan handler by itself.
The patch overrides D21289 for a better implementation (we're able to
rev up a single handler).

After this, then we can land a slight modification of D19667+D19668.

We probably don't want to keep all the versions in compiler-rt (maybe we
want to deprecate on one release and remove the old handler on the next
one?), but with this patch we will loudly fail to compile when mixing
incompatible handler calls, instead of silently compiling and then
providing bad error messages.

Reviewers: kcc, samsonov, rsmith, vsk

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D21695

llvm-svn: 289444

show more ...

[ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

On some Apple platforms, the ObjC BOOL type is defined as a signed char.
When performing instrumentation for -fsanitize=bool, we'd like to

[ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

On some Apple platforms, the ObjC BOOL type is defined as a signed char.
When performing instrumentation for -fsanitize=bool, we'd like to treat
the range of BOOL like it's always {0, 1}. While we can't change clang's
IRGen for char-backed BOOL's due to ABI compatibility concerns, we can
teach ubsan to catch potential abuses of this type.

rdar://problem/29502773

Differential Revision: https://reviews.llvm.org/D27607

llvm-svn: 289290

show more ...

[c++17] P0135R1: Guaranteed copy elision.

When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly

[c++17] P0135R1: Guaranteed copy elision.

When an object of class type is initialized from a prvalue of the same type
(ignoring cv qualifications), use the prvalue to initialize the object directly
instead of inserting a redundant elidable call to a copy constructor.

llvm-svn: 288866

show more ...

Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.

Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.

Recommit r287039 (that was reverted in r287039) with a tweak to
be more generic, and test fixes!

Differential Revision: https://reviews.llvm.org/D26522

llvm-svn: 287085

show more ...

Revert "Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks"

This reverts commit r287039, tests are broken.

llvm-svn: 287043

Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.

Improve handling of __FUNCTION__ and other predefined expression for Objective-C Blocks

Instead of always displaying the mangled name, try to do better
and get something closer to regular functions.

Differential Revision: https://reviews.llvm.org/D26522

llvm-svn: 287039

show more ...

[OPENMP] Fixed codegen for __real/__imag expressions in atomic
constructs.

For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but n

[OPENMP] Fixed codegen for __real/__imag expressions in atomic
constructs.

For __real/__imag unary expressions clang emits lvalue with the
associated type from the original complex expression, but not the
underlying builtin integer or float type. This causes crash in codegen
for atomic constructs, if __real/__imag expression are used in atomic
constructs.

llvm-svn: 286129

show more ...

[OPENMP] Fixed capturing of VLA variables.

After some changes in codegen capturing of VLA variables in OpenMP regions was broken, causing compiler crash. Patch fixes this issue.

llvm-svn: 286103

Revert "[OPENMP] Fixed capturing of VLA variables."

This reverts commit r286098 because the modified test breaks on many of the
buildbots.

llvm-svn: 286102

[OPENMP] Fixed capturing of VLA variables.

After some changes in codegen capturing of VLA variables in OpenMP
regions was broken, causing compiler crash. Patch fixes this issue.

llvm-svn: 286098

Refactor call emission to package the function pointer together with
abstract information about the callee. NFC.

The goal here is to make it easier to recognize indirect calls and
trigger additiona

Refactor call emission to package the function pointer together with
abstract information about the callee. NFC.

The goal here is to make it easier to recognize indirect calls and
trigger additional logic in certain cases. That logic will come in
a later patch; in the meantime, I felt that this was a significant
improvement to the code.

llvm-svn: 285258

show more ...

[CodeGen][ObjC] Do not call objc_storeStrong when initializing a
constexpr variable.

When compiling a constexpr NSString initialized with an objective-c
string literal, CodeGen emits objc_storeStron

[CodeGen][ObjC] Do not call objc_storeStrong when initializing a
constexpr variable.

When compiling a constexpr NSString initialized with an objective-c
string literal, CodeGen emits objc_storeStrong on an uninitialized
alloca, which causes a crash.

This patch folds the code in EmitScalarInit into EmitStoreThroughLValue
and fixes the crash by calling objc_retain on the string instead of
using objc_storeStrong.

rdar://problem/28562009

Differential Revision: https://reviews.llvm.org/D25547

llvm-svn: 284516

show more ...

[ubsan] Disable bounds-check for flexible array ivars

This eliminates a class of false positives for -fsanitize=array-bounds
on instrumented ObjC projects.

Differential Revision: https://reviews.ll

[ubsan] Disable bounds-check for flexible array ivars

This eliminates a class of false positives for -fsanitize=array-bounds
on instrumented ObjC projects.

Differential Revision: https://reviews.llvm.org/D22227

llvm-svn: 283249

show more ...

Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for th

Switch to a different workaround for unimplementability of P0145R3 in MS ABIs.
Instead of ignoring the evaluation order rule, ignore the "destroy parameters
in reverse construction order" rule for the small number of problematic cases.
This only causes incorrect behavior in the rare case where both parameters to
an overloaded operator <<, >>, ->*, &&, ||, or comma are of class type with
non-trivial destructor, and the program is depending on those parameters being
destroyed in reverse construction order.

We could do a little better here by reversing the order of parameter
destruction for those functions (and reversing the argument evaluation order
for all direct calls, not just those with operator syntax), but that is not a
complete solution to the problem, as the same situation can be reached by an
indirect function call.

Approach reviewed off-line by rnk.

llvm-svn: 282777

show more ...

Re-commit r282556, reverted in r282564, with a fix to CallArgList::addFrom to
function correctly when targeting MS ABIs (this appears to have never mattered
prior to this change).

Update test case t

Re-commit r282556, reverted in r282564, with a fix to CallArgList::addFrom to
function correctly when targeting MS ABIs (this appears to have never mattered
prior to this change).

Update test case to always cover both 32-bit and 64-bit Windows ABIs, since
they behave somewhat differently from each other here.

Update test case to also cover operators , && and ||, which it appears are also
affected by P0145R3 (they're not explicitly called out by the design document,
but this is the emergent behavior of the existing wording).


Original commit message:

P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)

This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).

llvm-svn: 282619

show more ...

Revert r282556. This change made several bots unhappy.

llvm-svn: 282564

P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)

This completes

P0145R3 (C++17 evaluation order tweaks): evaluate the right-hand side of
assignment and compound-assignment operators before the left-hand side. (Even
if it's an overloaded operator.)

This completes the implementation of P0145R3 + P0400R0 for all targets except
Windows, where the evaluation order guarantees for <<, >>, and ->* are
unimplementable as the ABI requires the function arguments are evaluated from
right to left (because parameter destructors are run from left to right in the
callee).

llvm-svn: 282556

show more ...