[ubsan] Add helpers to decide when null/vptr checks are required. NFC.

llvm-svn: 314750

[ubsan] Save a ptrtoint when emitting alignment checks

The alignment check emits a ptrtoint instruction which can be reused in
the call to the diagnostic handler.

llvm-svn: 314749

[CodeGen] Have a special function to get TBAA info for may-alias accesses

This is part of D37826 reworked to be a separate patch to
simplify review.

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

[CodeGen] Have a special function to get TBAA info for may-alias accesses

This is part of D37826 reworked to be a separate patch to
simplify review.

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

llvm-svn: 314660

show more ...

[CodeGen] Do not refer to complete TBAA info where we actually deal with just TBAA access types

This patch fixes misleading names of entities related to getting,
setting and generation of TBAA acces

[CodeGen] Do not refer to complete TBAA info where we actually deal with just TBAA access types

This patch fixes misleading names of entities related to getting,
setting and generation of TBAA access type descriptors.

This is effectively an attempt to provide a review for D37826 by
breaking it into smaller pieces.

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

llvm-svn: 314657

show more ...

[OpenCL] Handle address space conversion while setting type alignment.

Added missing addrspacecast case in alignment computation
logic of pointer type emission in IR generation.

Differential Revisi

[OpenCL] Handle address space conversion while setting type alignment.

Added missing addrspacecast case in alignment computation
logic of pointer type emission in IR generation.

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

llvm-svn: 314304

show more ...

Allow specifying sanitizers in blacklists

Summary:
This is the follow-up patch to D37924.

This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which

Allow specifying sanitizers in blacklists

Summary:
This is the follow-up patch to D37924.

This change refactors clang to use the the newly added section headers
in SpecialCaseList to specify which sanitizers blacklists entries
should apply to, like so:

[cfi-vcall]
fun:*bad_vcall*
[cfi-derived-cast|cfi-unrelated-cast]
fun:*bad_cast*

The SanitizerSpecialCaseList class has been added to allow querying by
SanitizerMask, and SanitizerBlacklist and its downstream users have been
updated to provide that information. Old blacklists not using sections
will continue to function identically since the blacklist entries will
be placed into a '[*]' section by default matching against all
sanitizers.

Reviewers: pcc, kcc, eugenis, vsk

Reviewed By: eugenis

Subscribers: dberris, cfe-commits, mgorny

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

llvm-svn: 314171

show more ...

[ubsan] Function Sanitizer: Don't require writable text segments

This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the wa

[ubsan] Function Sanitizer: Don't require writable text segments

This change will make it possible to use -fsanitize=function on Darwin and
possibly on other platforms. It fixes an issue with the way RTTI is stored into
function prologue data.

On Darwin, addresses stored in prologue data can't require run-time fixups and
must be PC-relative. Run-time fixups are undesirable because they necessitate
writable text segments, which can lead to security issues. And absolute
addresses are undesirable because they break PIE mode.

The fix is to create a private global which points to the RTTI, and then to
encode a PC-relative reference to the global into prologue data.

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

llvm-svn: 313096

show more ...

[CodeGen] Treat all vector fields as mayalias

Because it is common to treat vector types as an array of their elements, or
even some other type that's not the element type, and thus index into them,

[CodeGen] Treat all vector fields as mayalias

Because it is common to treat vector types as an array of their elements, or
even some other type that's not the element type, and thus index into them, we
can't use struct-path TBAA for these accesses. Even though we already treat all
vector types as equivalent to 'char', we were using field-offset information
for them with TBAA, and this renders undefined the intra-value indexing we
intend to allow. Note that, although 'char' is universally aliasing, with path
TBAA, we can still differentiate between access to s.a and s.b in
struct { char a, b; } s;. We can't use this capability as-is for vector types.

Fixes PR33967.

llvm-svn: 312447

show more ...

Minimal runtime for UBSan.

Summary:
An implementation of ubsan runtime library suitable for use in production.

Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_

Minimal runtime for UBSan.

Summary:
An implementation of ubsan runtime library suitable for use in production.

Minimal attack surface.
* No stack traces.
* Definitely no C++ demangling.
* No UBSAN_OPTIONS=log_file=/path (very suid-unfriendly). And no UBSAN_OPTIONS in general.
* as simple as possible

Minimal CPU and RAM overhead.
* Source locations unnecessary in the presence of (split) debug info.
* Values and types (as in A+B overflows T) can be reconstructed from register/stack dumps, once you know what type of error you are looking at.
* above two items save 3% binary size.

When UBSan is used with -ftrap-function=abort, sometimes it is hard to reason about failures. This library replaces abort with a slightly more informative message without much extra overhead. Since ubsan interface in not stable, this code must reside in compiler-rt.

Reviewers: pcc, kcc

Subscribers: srhines, mgorny, aprantl, krytarowski, llvm-commits

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

llvm-svn: 312029

show more ...

[IRGen] Evaluate constant static variables referenced through member
expressions

C++ allows us to reference static variables through member expressions. Prior to
this commit, non-integer static vari

[IRGen] Evaluate constant static variables referenced through member
expressions

C++ allows us to reference static variables through member expressions. Prior to
this commit, non-integer static variables that were referenced using a member
expression were always emitted using lvalue loads. The old behaviour introduced
an inconsistency between regular uses of static variables and member expressions
uses. For example, the following program compiled and linked successfully:

struct Foo {
constexpr static const char *name = "foo";
};
int main() {
return Foo::name[0] == 'f';
}

but this program failed to link because "Foo::name" wasn't found:

struct Foo {
constexpr static const char *name = "foo";
};
int main() {
Foo f;
return f.name[0] == 'f';
}

This commit ensures that constant static variables referenced through member
expressions are emitted in the same way as ordinary static variable references.

rdar://33942261

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

llvm-svn: 311772

show more ...

[OPENMP] Fix for PR34014: OpenMP 4.5: Target construct in static method
of class fails to map class static variable.

If the global variable is captured and it has several redeclarations,
sometimes i

[OPENMP] Fix for PR34014: OpenMP 4.5: Target construct in static method
of class fails to map class static variable.

If the global variable is captured and it has several redeclarations,
sometimes it may lead to a compiler crash. Patch fixes this by working
only with canonical declarations.

llvm-svn: 311479

show more ...

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit

Extract IRGen's constant-emitter into its own helper class and clean up
the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit constant initializers that have
ignorable side-effects, or doing the majority of an initialization
in-place and then patching up the last few things with calls. But for
now this is mostly just a refactoring.

llvm-svn: 310964

show more ...

Add OpenCL 2.0 atomic builtin functions as Clang builtin

OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instr

Add OpenCL 2.0 atomic builtin functions as Clang builtin

OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instructions.

Clang supports translating Clang atomic builtin functions to LLVM atomic
instructions. However it currently does not support synchronization scope
of LLVM atomic instructions. Without this, users have to use LLVM assembly
code to implement OpenCL atomic builtin functions.

This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin
functions, which supports generating LLVM atomic instructions with
synchronization scope operand.

Currently only constant memory scope argument is supported. Support of
non-constant memory scope argument will be added later.

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

llvm-svn: 310082

show more ...

[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available

In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two check

[ubsan] Have -fsanitize=vptr emit a null check if -fsanitize=null isn't available

In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.

In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.

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

llvm-svn: 309846

show more ...

[ubsan] Null-check pointers in -fsanitize=vptr (PR33881)

The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face o

[ubsan] Null-check pointers in -fsanitize=vptr (PR33881)

The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.

The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.

Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build

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

https://bugs.llvm.org/show_bug.cgi?id=33881

llvm-svn: 309007

show more ...

CodeGen: Insert addr space cast for automatic/temp var at right position

The uses of alloca may be in different blocks other than the block containing the alloca.
Therefore if the alloca addr space

CodeGen: Insert addr space cast for automatic/temp var at right position

The uses of alloca may be in different blocks other than the block containing the alloca.
Therefore if the alloca addr space is non-zero and it needs to be casted to default
address space, the cast needs to be inserted in the same BB as the alloca insted of
the current builder insert point since the current insert point may be in a different BB.

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

llvm-svn: 308313

show more ...

[ubsan] Teach the pointer overflow check that "p - <unsigned> <= p" (PR33430)

The pointer overflow check gives false negatives when dealing with
expressions in which an unsigned value is subtracted

[ubsan] Teach the pointer overflow check that "p - <unsigned> <= p" (PR33430)

The pointer overflow check gives false negatives when dealing with
expressions in which an unsigned value is subtracted from a pointer.
This is summarized in PR33430 [1]: ubsan permits the result of the
subtraction to be greater than "p", but it should not.

To fix the issue, we should track whether or not the pointer expression
is a subtraction. If it is, and the indices are unsigned, we know to
expect "p - <unsigned> <= p".

I've tested this by running check-{llvm,clang} with a stage2
ubsan-enabled build. I've also added some tests to compiler-rt, which
are in D34122.

[1] https://bugs.llvm.org/show_bug.cgi?id=33430

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

llvm-svn: 307955

show more ...

CodeGen: Fix address space of global variable

Certain targets (e.g. amdgcn) require global variable to stay in global or constant address
space. In C or C++ global variables are emitted in the defau

CodeGen: Fix address space of global variable

Certain targets (e.g. amdgcn) require global variable to stay in global or constant address
space. In C or C++ global variables are emitted in the default (generic) address space.
This patch introduces virtual functions TargetCodeGenInfo::getGlobalVarAddressSpace
and TargetInfo::getConstantAddressSpace to handle this in a general approach.

It only affects IR generated for amdgcn target.

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

llvm-svn: 307470

show more ...

CodeGen: Cast temporary variable to proper address space

In C++ all variables are in default address space. Previously change has been
made to cast automatic variables to default address space. Howe

CodeGen: Cast temporary variable to proper address space

In C++ all variables are in default address space. Previously change has been
made to cast automatic variables to default address space. However that is
not sufficient since all temporary variables need to be casted to default
address space.

This patch casts all temporary variables to default address space except those
for passing indirect arguments since they are only used for load/store.

This patch only affects target having non-zero alloca address space.

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

llvm-svn: 305711

show more ...

[ubsan] PR33081: Skip the standard type checks for volatile

Skip checks for null dereference, alignment violation, object size
violation, and dynamic type violation if the pointer points to volatile

[ubsan] PR33081: Skip the standard type checks for volatile

Skip checks for null dereference, alignment violation, object size
violation, and dynamic type violation if the pointer points to volatile
data.

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

llvm-svn: 305546

show more ...

[coroutines] Allow co_await and co_yield expressions that return an lvalue to compile

Summary:
The title says it all.


Reviewers: GorNishanov, rsmith

Reviewed By: GorNishanov

Subscribers: rjmccal

[coroutines] Allow co_await and co_yield expressions that return an lvalue to compile

Summary:
The title says it all.


Reviewers: GorNishanov, rsmith

Reviewed By: GorNishanov

Subscribers: rjmccall, cfe-commits

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

llvm-svn: 305496

show more ...

[ubsan] Detect invalid unsigned pointer index expression (clang)

Adding an unsigned offset to a base pointer has undefined behavior if
the result of the expression would precede the base. An example

[ubsan] Detect invalid unsigned pointer index expression (clang)

Adding an unsigned offset to a base pointer has undefined behavior if
the result of the expression would precede the base. An example from
@regehr:

int foo(char *p, unsigned offset) {
return p + offset >= p; // This may be optimized to '1'.
}

foo(p, -1); // UB.

This patch extends the pointer overflow check in ubsan to detect invalid
unsigned pointer index expressions. It changes the instrumentation to
only permit non-negative offsets in pointer index expressions when all
of the GEP indices are unsigned.

Testing: check-llvm, check-clang run on a stage2, ubsan-instrumented
build.

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

llvm-svn: 305216

show more ...

[DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.

Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit a

[DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.

Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.

Reviewers: rjmccall, aaron.ballman

Subscribers: cfe-commits

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

llvm-svn: 305075

show more ...

Don't assume that a store source is a vector type just because the destination is (PR26099)

llvm-svn: 304465

[ubsan] Add a check for pointer overflow UB

Check pointer arithmetic for overflow.

For some more background on this check, see:

https://wdtz.org/catching-pointer-overflow-bugs.html
https://rev

[ubsan] Add a check for pointer overflow UB

Check pointer arithmetic for overflow.

For some more background on this check, see:

https://wdtz.org/catching-pointer-overflow-bugs.html
https://reviews.llvm.org/D20322

Patch by Will Dietz and John Regehr!

This version of the patch is different from the original in a few ways:

- It introduces the EmitCheckedInBoundsGEP utility which inserts
checks when the pointer overflow check is enabled.

- It does some constant-folding to reduce instrumentation overhead.

- It does not check some GEPs in CGExprCXX. I'm not sure that
inserting checks here, or in CGClass, would catch many bugs.

Possible future directions for this check:

- Introduce CGF.EmitCheckedStructGEP, to detect overflows when
accessing structures.

Testing: Apart from the added lit test, I ran check-llvm and check-clang
with a stage2, ubsan-instrumented clang. Will and John have also done
extensive testing on numerous open source projects.

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

llvm-svn: 304459

show more ...