Fix always_inline 'target' compatibility check code for Lambdas

The previous version of this used CurFuncDecl in CodeGenFunction,
however this doesn't include lambdas. However, CurCodeDecl DOES. Sw

Fix always_inline 'target' compatibility check code for Lambdas

The previous version of this used CurFuncDecl in CodeGenFunction,
however this doesn't include lambdas. However, CurCodeDecl DOES. Switch
the check to use CurCodeDecl so that the actual function being emitted
gets checked, preventing an error in ISEL.

llvm-svn: 370261

show more ...

hwasan, codegen: Keep more lifetime markers used for hwasan

Reviewers: eugenis

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 369980

msan, codegen, instcombine: Keep more lifetime markers used for msan

Reviewers: eugenis

Subscribers: hiraditya, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

Differentia

msan, codegen, instcombine: Keep more lifetime markers used for msan

Reviewers: eugenis

Subscribers: hiraditya, cfe-commits, #sanitizers, llvm-commits

Tags: #clang, #sanitizers, #llvm

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

llvm-svn: 369979

show more ...

[CodeGen] Disable UBSan for coroutine functions

Summary:
As explained in http://lists.llvm.org/pipermail/llvm-dev/2018-March/121924.html,
the LLVM coroutines transforms are not yet able to move the

[CodeGen] Disable UBSan for coroutine functions

Summary:
As explained in http://lists.llvm.org/pipermail/llvm-dev/2018-March/121924.html,
the LLVM coroutines transforms are not yet able to move the
instructions for UBSan null checking past coroutine suspend boundaries.
For now, disable all UBSan checks when generating code for coroutines
functions.

I also considered an approach where only '-fsanitize=null' would be disabled,
However in practice this led to other LLVM errors when writing object files:
"Cannot represent a difference across sections". For now, disable all
UBSan checks until coroutine transforms are updated to handle them.

Test Plan:
1. check-clang
2. Compile the program in https://gist.github.com/modocache/54a036c3bf9c06882fe85122e105d153
using the '-fsanitize=null' option and confirm it does not crash
during LLVM IR generation.

Reviewers: GorNishanov, vsk, eric_niebler, lewissbaker

Reviewed By: vsk

Subscribers: cfe-commits

Tags: #clang

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

llvm-svn: 368675

show more ...

cfi-icall: Allow the jump table to be optionally made non-canonical.

The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the outpu

cfi-icall: Allow the jump table to be optionally made non-canonical.

The default behavior of Clang's indirect function call checker will replace
the address of each CFI-checked function in the output file's symbol table
with the address of a jump table entry which will pass CFI checks. We refer
to this as making the jump table `canonical`. This property allows code that
was not compiled with ``-fsanitize=cfi-icall`` to take a CFI-valid address
of a function, but it comes with a couple of caveats that are especially
relevant for users of cross-DSO CFI:

- There is a performance and code size overhead associated with each
exported function, because each such function must have an associated
jump table entry, which must be emitted even in the common case where the
function is never address-taken anywhere in the program, and must be used
even for direct calls between DSOs, in addition to the PLT overhead.

- There is no good way to take a CFI-valid address of a function written in
assembly or a language not supported by Clang. The reason is that the code
generator would need to insert a jump table in order to form a CFI-valid
address for assembly functions, but there is no way in general for the
code generator to determine the language of the function. This may be
possible with LTO in the intra-DSO case, but in the cross-DSO case the only
information available is the function declaration. One possible solution
is to add a C wrapper for each assembly function, but these wrappers can
present a significant maintenance burden for heavy users of assembly in
addition to adding runtime overhead.

For these reasons, we provide the option of making the jump table non-canonical
with the flag ``-fno-sanitize-cfi-canonical-jump-tables``. When the jump
table is made non-canonical, symbol table entries point directly to the
function body. Any instances of a function's address being taken in C will
be replaced with a jump table address.

This scheme does have its own caveats, however. It does end up breaking
function address equality more aggressively than the default behavior,
especially in cross-DSO mode which normally preserves function address
equality entirely.

Furthermore, it is occasionally necessary for code not compiled with
``-fsanitize=cfi-icall`` to take a function address that is valid
for CFI. For example, this is necessary when a function's address
is taken by assembly code and then called by CFI-checking C code. The
``__attribute__((cfi_jump_table_canonical))`` attribute may be used to make
the jump table entry of a specific function canonical so that the external
code will end up taking a address for the function that will pass CFI checks.

Fixes PR41972.

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

llvm-svn: 368495

show more ...

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software impl

ARM MTE stack sanitizer.

Add "memtag" sanitizer that detects and mitigates stack memory issues
using armv8.5 Memory Tagging Extension.

It is similar in principle to HWASan, which is a software implementation
of the same idea, but there are enough differencies to warrant a new
sanitizer type IMHO. It is also expected to have very different
performance properties.

The new sanitizer does not have a runtime library (it may grow one
later, along with a "debugging" mode). Similar to SafeStack and
StackProtector, the instrumentation pass (in a follow up change) will be
inserted in all cases, but will only affect functions marked with the
new sanitize_memtag attribute.

Reviewers: pcc, hctim, vitalybuka, ostannard

Subscribers: srhines, mehdi_amini, javed.absar, kristof.beyls, hiraditya, cryptoad, steven_wu, dexonsmith, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 366123

show more ...

Ensure Target Features always_inline error happens in C++ cases.

A handful of C++ cases as reported in PR42352 didn't actually give an
error when always_inlining with a different target feature list

Ensure Target Features always_inline error happens in C++ cases.

A handful of C++ cases as reported in PR42352 didn't actually give an
error when always_inlining with a different target feature list. This
resulted in broken IR.

llvm-svn: 364109

show more ...

Store a pointer to the return value in a static alloca and let the debugger use that
as the variable address for NRVO variables.

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llv

Store a pointer to the return value in a static alloca and let the debugger use that
as the variable address for NRVO variables.

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 363952

show more ...

Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but s

Refactor: split Uninitialized state on APValue into an "Absent" state
representing no such object, and an "Indeterminate" state representing
an uninitialized object. The latter is not yet used, but soon will be.

llvm-svn: 361328

show more ...

[OpenCL] Make global ctor init function a kernel

We need to be able to enqueue internal function that initializes
global constructors on the host side. Therefore it has to be
converted to a kernel.

[OpenCL] Make global ctor init function a kernel

We need to be able to enqueue internal function that initializes
global constructors on the host side. Therefore it has to be
converted to a kernel.

This change factors out common logic for adding kernel metadata
and moves it from CodeGenFunction to CodeGenModule in order to
make it accessible for the extra use case.

Differential revision: https://reviews.llvm.org/D61488

llvm-svn: 360342

show more ...

Recommit r359859 "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"

Updated with fix for read of uninitialized memory.

llvm-svn: 360109

Revert "[Attribute/Diagnostics] Print macro if definition is an attribute declaration"

This reverts commit fc40cbd9d8c63e65eed3590ba925321afe782e1d.

llvm-svn: 359859

[Attribute/Diagnostics] Print macro if definition is an attribute declaration

If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for inco

[Attribute/Diagnostics] Print macro if definition is an attribute declaration

If an address_space attribute is defined in a macro, print the macro instead
when diagnosing a warning or error for incompatible pointers with different
address_spaces.

We allow this for all attributes (not just address_space), and for multiple
attributes declared in the same macro.

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

llvm-svn: 359826

show more ...

Don't emit an unreachable return block.

Patch by Brad Moody.

llvm-svn: 358104

[opaque pointer types] Trivial changes towards CallInst requiring
explicit function types.

llvm-svn: 353009

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[clang][UBSan] Sanitization for alignment assumptions.

Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3:

[clang][UBSan] Sanitization for alignment assumptions.

Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```

This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.

Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.

This is a second commit, the original one was r351105,
which was mass-reverted in r351159 because 2 compiler-rt tests were failing.

Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall

Reviewed By: rjmccall

Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer

Tags: #sanitizers

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

llvm-svn: 351177

show more ...

Revert alignment assumptions changes

Revert r351104-6, r351109, r351110, r351119, r351134, and r351153. These
changes fail on the sanitizer bots.

llvm-svn: 351159

[clang][UBSan] Sanitization for alignment assumptions.

Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3:

[clang][UBSan] Sanitization for alignment assumptions.

Summary:
UB isn't nice. It's cool and powerful, but not nice.
Having a way to detect it is nice though.
[[ https://wg21.link/p1007r3 | P1007R3: std::assume_aligned ]] / http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1007r2.pdf says:
```
We propose to add this functionality via a library function instead of a core language attribute.
...
If the pointer passed in is not aligned to at least N bytes, calling assume_aligned results in undefined behaviour.
```

This differential teaches clang to sanitize all the various variants of this assume-aligned attribute.

Requires D54588 for LLVM IRBuilder changes.
The compiler-rt part is D54590.

Reviewers: ABataev, craig.topper, vsk, rsmith, rnk, #sanitizers, erichkeane, filcab, rjmccall

Reviewed By: rjmccall

Subscribers: chandlerc, ldionne, EricWF, mclow.lists, cfe-commits, bkramer

Tags: #sanitizers

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

llvm-svn: 351105

show more ...

[AST] Remove ASTContext from getThisType (NFC)

Summary:
https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from
within the `CXXMethodDecl::getThisType` method. Remove the parameter

[AST] Remove ASTContext from getThisType (NFC)

Summary:
https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from
within the `CXXMethodDecl::getThisType` method. Remove the parameter
altogether, as well as all usages of it. This does not result in any
functional change because the parameter was unused since
https://reviews.llvm.org/D54862.

Test Plan: check-clang

Reviewers: akyrtzi, mikael

Reviewed By: mikael

Subscribers: mehdi_amini, dexonsmith, cfe-commits

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

llvm-svn: 350914

show more ...

[NFC] Fix usage of Builder.insert(new Bitcast...)in CodeGenFunction

This is exactly a "CreateBitCast", so refactor this to get rid of a
'new'.

Note that this slightly changes the test, as the Build

[NFC] Fix usage of Builder.insert(new Bitcast...)in CodeGenFunction

This is exactly a "CreateBitCast", so refactor this to get rid of a
'new'.

Note that this slightly changes the test, as the Builder is now
seemingly smart enough to fold one of the bitcasts into the annotation
call.

Change-Id: I1733fb1fdf91f5c9d88651067130b9a4e7b5ab67
llvm-svn: 349506

show more ...

Remove unused Args parameter from EmitFunctionBody, NFC

llvm-svn: 349001

Teach __builtin_unpredictable to work through implicit casts.

The __builtin_unpredictable implementation is confused by any implicit
casts, which happen in C++. This patch strips those off so that

Teach __builtin_unpredictable to work through implicit casts.

The __builtin_unpredictable implementation is confused by any implicit
casts, which happen in C++. This patch strips those off so that
if/switch statements now work with it in C++.

Change-Id: I73c3bf4f1775cd906703880944f4fcdc29fffb0a
llvm-svn: 348969

show more ...

Move CodeGenOptions from Frontend to Basic

Basic uses CodeGenOptions and should not depend on Frontend.

llvm-svn: 348827

Fix thunks returning memptrs via sret by emitting also scalar return values directly in sret slot (PR39901)

Thunks that return member pointers via sret are broken due to using temporary
storage for

Fix thunks returning memptrs via sret by emitting also scalar return values directly in sret slot (PR39901)

Thunks that return member pointers via sret are broken due to using temporary
storage for the return value on the stack and then passing that pointer to a
tail call, violating the rule that a tail call can't access allocas in the
caller (see bug).

Since r90526, we put aggregate return values directly in the sret slot, but
this doesn't apply to member pointers which are considered scalar.

Unless I'm missing something subtle, we should be able to always use the sret
slot directly for indirect return values.

Differential revision: https://reviews.llvm.org/D55371

llvm-svn: 348569

show more ...