Put the implicit weak sized deallocation funciton in C++14 in a comdat

Fixes PR22635.

llvm-svn: 229913

Rename flags and options to match current naming: from -fdef-sized-delete to -fdefine-sized-deallocation, and from DefaultSizedDelete to DefineSizedDeallocation.

llvm-svn: 229597

Revise the implementation logic of sized deallocation: Do not automatically generate weak definitions of the sized operator delete (in terms of unsized operator delete). Instead, provide the funciton

Revise the implementation logic of sized deallocation: Do not automatically generate weak definitions of the sized operator delete (in terms of unsized operator delete). Instead, provide the funcitonality via a new compiler flag, -fdef-sized-delete.
The current implementation causes link-time ODR violations when the delete symbols are exported into the dynamic table.

llvm-svn: 229241

show more ...

SEH: Use the SEHTryEpilogueStack instead of a separate bool

We don't need a bool to track this now that we have a stack for it.

llvm-svn: 228982

Add the 'noinline' attribute to call sites within __try bodies

LLVM doesn't support non-call exceptions, so inlining makes it harder to
catch such asynchronous exceptions.

llvm-svn: 228876

Implement IRGen for SEH __finally and AbnormalTermination

Previously we would simply double-emit the body of the __finally block,
but that doesn't work when it contains any kind of Decl, which we ca

Implement IRGen for SEH __finally and AbnormalTermination

Previously we would simply double-emit the body of the __finally block,
but that doesn't work when it contains any kind of Decl, which we can't
double emit.

This fixes that by emitting the block once and branching into a shared
code region and then branching back out.

llvm-svn: 228222

show more ...

DebugInfo: Attribute cleanup code to the end of the scope, not the end of the function.

Now if you break on a dtor and go 'up' in your debugger (or you get an
asan failure in a dtor) during an excep

DebugInfo: Attribute cleanup code to the end of the scope, not the end of the function.

Now if you break on a dtor and go 'up' in your debugger (or you get an
asan failure in a dtor) during an exception unwind, you'll have more
context. Instead of all dtors appearing to be called from the '}' of the
function, they'll be attributed to the end of the scope of the variable,
the same as the non-exceptional dtor call.

This doesn't /quite/ remove all uses of CurEHLocation (which might be
nice to remove, for a few reasons) - it's still used to choose the
location for some other work in the landing pad. It'd be nice to
attribute that code to the same location as the exception calls within
the block and to remove CurEHLocation.

llvm-svn: 228181

show more ...

DebugInfo: Fix line table for comparisons harder/better for the sake of C (& the GDB buildbot)

llvm-svn: 227663

DebugInfo: Attribute implicit boolean tests to the expression being tested, not to the outer use of that expression.

This is half a fix for a GDB test suite failure that expects to start at
'a' in t

DebugInfo: Attribute implicit boolean tests to the expression being tested, not to the outer use of that expression.

This is half a fix for a GDB test suite failure that expects to start at
'a' in the following code:

void func(int a)
if (a
&&
b)
...

But instead, without this change, the comparison was assigned to '&&'
(well, worse actually - because there was a chained 'a && b && c' and it
was assigned to the second '&&' because of a recursive application of
this bug) and then the load folded into the comparison so breaking on
the function started at '&&' instead of 'a'.

The other part of this needs to be fixed in LLVM where it's ignoring the
location of the icmp and instead using the location of the branch
instruction.

The fix to the conditional operator is actually a no-op currently,
because the conditional operator's location coincides with 'a' (the
start of the conditional expression) but should probably be '?' instead.
See the FIXME in the test case that mentions the ARCMigration tool
failures when I tried to make that change.

llvm-svn: 227356

show more ...

Initial support for Win64 SEH IR emission

The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching

Initial support for Win64 SEH IR emission

The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.

Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.

The IR lowering looks like this:

// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}

; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}

define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad

normal:
store i32 %rr, i32* %r
ret i1 1

lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume

eh.except:
ret i1 false

eh.resume:
resume
}

Reviewers: rjmccall, rsmith, majnemer

Differential Revision: http://reviews.llvm.org/D5607

llvm-svn: 226760

show more ...

Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).

Several pieces of code were relying on implicit debug location setting
which usuall

Reapply r225000 (reverted in r225555): DebugInfo: Generalize debug info location handling (and follow-up commits).

Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.

The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.

There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.

Original commit message:

Reapply "DebugInfo: Generalize debug info location handling"

Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).

Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.

Original commit message:

This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.

This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.

I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.

Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.

I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.

llvm-svn: 225956

show more ...

Revert "DebugInfo: Generalize debug info location handling" and related commits

This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues w

Revert "DebugInfo: Generalize debug info location handling" and related commits

This reverts commit r225000, r225021, r225083, r225086, r225090.

The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.

I'll work up some test cases and fixes before recommitting this.

llvm-svn: 225555

show more ...

DebugInfo: Provide a less subtle way to set the debug location of simple ret instructions

un-XFAILing the test XFAIL'd in r225086 after it regressed in r225083.

llvm-svn: 225090

OpenCL C: Add support for a set of floating point
arithmetic relaxation flags:

-cl-no-signed-zeros
-cl-unsafe-math-optimizations
-cl-finite-math-only
-cl-fast-relaxed-math

Propagate the info to FP

OpenCL C: Add support for a set of floating point
arithmetic relaxation flags:

-cl-no-signed-zeros
-cl-unsafe-math-optimizations
-cl-finite-math-only
-cl-fast-relaxed-math

Propagate the info to FP instruction flags as well
as function attributes where they are available.

llvm-svn: 223928

show more ...

IR: Update clang for Metadata/Value split in r223802

Match LLVM API changes from r223802.

llvm-svn: 223803

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

ll

InstrProf: Use LLVM's -instrprof pass for profiling

The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.

llvm-svn: 223683

show more ...

Always emit kernel arg info for SPIR.

http://llvm.org/bugs/show_bug.cgi?id=21555

Currently, kernel argument metadata is omitted unless the
"-cl-kernel-arg-info" option is specified. But the SPIR 1.

Always emit kernel arg info for SPIR.

http://llvm.org/bugs/show_bug.cgi?id=21555

Currently, kernel argument metadata is omitted unless the
"-cl-kernel-arg-info" option is specified. But the SPIR 1.2 spec
requires that all metadata except kernel_arg_name should always be
emitted, and kernel_arg_name is only emitted when
"-cl-kernel-arg-info" is specified.

Patch ported by Ryan Burn from the Khronos SPIR generator.
https://github.com/KhronosGroup/SPIR

llvm-svn: 223340

show more ...

UBSan now uses prologue data instead of prefix data

As the semantics of prefix data has changed. See D6454.

Patch by Ben Gamari!

Test Plan: Testsuite

Differential Revision: http://reviews.llvm.or

UBSan now uses prologue data instead of prefix data

As the semantics of prefix data has changed. See D6454.

Patch by Ben Gamari!

Test Plan: Testsuite

Differential Revision: http://reviews.llvm.org/D6489

llvm-svn: 223190

show more ...

Bundle conditions checked by UBSan with sanitizer kinds they implement.

Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to

Bundle conditions checked by UBSan with sanitizer kinds they implement.

Summary:
This change makes CodeGenFunction::EmitCheck() take several
conditions that needs to be checked (all of them need to be true),
together with sanitizer kinds these checks are for. This would allow
to split one call into UBSan runtime into several calls in case
different sanitizer kinds would have different recoverability
settings.

Tests should be fixed accordingly, I'm working on it.

Test Plan: regression test suite.

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D6219

llvm-svn: 221716

show more ...

Propagate SanitizerKind into CodeGenFunction::EmitCheck() call.

Make sure CodeGenFunction::EmitCheck() knows which sanitizer
it emits check for. Make CheckRecoverableKind enum an
implementation deta

Propagate SanitizerKind into CodeGenFunction::EmitCheck() call.

Make sure CodeGenFunction::EmitCheck() knows which sanitizer
it emits check for. Make CheckRecoverableKind enum an
implementation detail and move it away from header.

Currently CheckRecoverableKind is determined by the type of
sanitizer ("unreachable" and "return" are unrecoverable,
"vptr" is always-recoverable, all the rest are recoverable).
This will change in future if we allow to specify which sanitizers
are recoverable, and which are not by -fsanitize-recover= flag.

No functionality change.

llvm-svn: 221635

show more ...

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled san

Introduce a SanitizerKind enum to LangOptions.

Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.

No functionality change.

llvm-svn: 221558

show more ...

MS ABI: Properly call global delete when invoking virtual destructors

Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of informatio

MS ABI: Properly call global delete when invoking virtual destructors

Summary:
The Itanium ABI approach of using offset-to-top isn't possible with the
MS ABI, it doesn't have that kind of information lying around.

Instead, we do the following:
- Call the virtual deleting destructor with the "don't delete the object
flag" set. The virtual deleting destructor will return a pointer to
'this' adjusted to the most derived class.
- Call the global delete using the adjusted 'this' pointer.

Reviewers: rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D5996

llvm-svn: 220993

show more ...

Get rid of SanitizerOptions::Disabled global. NFC.

SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
met

Get rid of SanitizerOptions::Disabled global. NFC.

SanitizerOptions is not even a POD now, so having global variable of
this type, is not nice. Instead, provide a regular constructor and clear()
method, and let each CodeGenFunction has its own copy of SanitizerOptions
it uses.

llvm-svn: 220920

show more ...

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and tur

SanitizerBlacklist: blacklist functions by their source location.

This commit changes the way we blacklist functions in ASan, TSan,
MSan and UBSan. We used to treat function as "blacklisted"
and turned off instrumentation in it in two cases:

1) Function is explicitly blacklisted by its mangled name.
This part is not changed.

2) Function is located in llvm::Module, whose identifier is
contained in the list of blacklisted sources. This is completely
wrong, as llvm::Module may not correspond to the actual source
file function is defined in. Also, function can be defined in
a header, in which case user had to blacklist the .cpp file
this header was #include'd into, not the header itself.
Such functions could cause other problems - for instance, if the
header was included in multiple source files, compiled
separately and linked into a single executable, we could end up
with both instrumented and non-instrumented version of the same
function participating in the same link.

After this change we will make blacklisting decision based on
the SourceLocation of a function definition. If a function is
not explicitly defined in the source file, (for example, the
function is compiler-generated and responsible for
initialization/destruction of a global variable), then it will
be blacklisted if the corresponding global variable is defined
in blacklisted source file, and will be instrumented otherwise.

After this commit, the active users of blacklist files may have
to revisit them. This is a backwards-incompatible change, but
I don't think it's possible or makes sense to support the
old incorrect behavior.

I plan to make similar change for blacklisting GlobalVariables
(which is ASan-specific).

llvm-svn: 219997

show more ...

Formatting for prior commit

llvm-svn: 219692