"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226784
This function has been just included with the initial support for C++
parameter completion and it's trivial enough to be a static member.
llvm-svn: 226780
record, and that class declaration is not the canonical definition of the
class, be sure to add the class to the list of classes that are consulted when
we look up a special member in the canonical definition.
llvm-svn: 226778
on top of a local declaration of the same entity, we still need to remember
that we loaded the first one or we may fail to merge the second one properly.
llvm-svn: 226765
We don't emit any coverage mapping for uncovered functions that come
from system headers, but we were creating a GlobalVariable with each
of their names. This is wasteful since the linker will need to dead
strip the unused symbols, and it can lead to issues when merging
coverage with others TUs that do have coverage for those functions.
llvm-svn: 226764
load the definition data from the declaration itself. In that case, merge
properly; don't assume the prior definition is the same as our own.
llvm-svn: 226761
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
It fails on Windows due to another temporary being emitted first, so the
LLVM internal renaming scheme gives out the name
__block_descriptor_tmp1.
llvm-svn: 226757
Importing _Builtin_intrinsics.sse and avx would transitively pull in those
headers, and the test would fail when building in an environment where
they were not available on the include path.
This fixes PR20995 for me.
Differential Revision: http://reviews.llvm.org/D7112
llvm-svn: 226754
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
llvm-svn: 226751
Summary: cl::HideUnrelatedOptions allows tools to hide all options not part of a specific OptionCategory. This is the common use case for cl::getRegisteredOptions, which should be deprecated in the future because it exposes implementation details of command line parsing.
Reviewers: dexonsmith
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D7109
llvm-svn: 226741
This workaround was to provide unique call sites to ensure LLVM's inline
debug info handling would properly unique two calls to the same function
on the same line. Instead, this has now been fixed in LLVM (r226736) and
the workaround here can be removed.
Originally committed in r176895, but this isn't a straight revert due to
all the changes since then. I just searched for anything ForcedColumn*
related and removed them.
We could test this - but it didn't strike me as terribly valuable once
we're no longer adding this workaround everything just works as expected
& it's no longer a special case to test for.
llvm-svn: 226738
This test will start failing shortly once this bug is fixed in LLVM. At
that point this behavior is no longer required in Clang and will be
removed. In the interim, remove this test just to avoid the race between
the LLVM and Clang commits.
After the LLVM commit, I'll cleanup the workaround behavior in Clang.
llvm-svn: 226735
This attribute implies indicates that the function musttail calls
another function and returns whatever it returns. The return type of the
thunk is meaningless, as the thunk can dynamically call different
functions with different return types. So long as the callers bitcast
the thunk with the correct type, behavior is well defined.
This attribute was necessary to fix PR20944, where the indirect call
combiner noticed that the thunk returned void and replaced the results
of the indirect call instruction with undef.
Over-the-shoulder reviewed by David Majnemer.
llvm-svn: 226707
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
llvm-svn: 226670
We didn't consider any alignment attributes on an EnumDecl when
calculating alignment.
While we are here, ignore alignment specifications on typedef types if
one is used as the underlying type. Otherwise, weird things happen:
enum Y : int;
Y y;
typedef int __attribute__((aligned(64))) u;
enum Y : u {};
What is the alignment of 'Y'? It would be more consistent with the
overall design of enums with fixed underlying types to consider the
underlying type's UnqualifiedDesugaredType.
This fixes PR22279.
llvm-svn: 226653
be corrected.
This fixes PR22250, which exposed the bug where if there's more than one
TypoExpr in the arguments, once one failed to be corrected none of the
TypoExprs after it would be handled at all thanks to an early return.
llvm-svn: 226624
The test case is based on the reduction from PR21679 and has to be
freestanding to work correctly, since some of the expected errors (and
some of the problems that were fixed) only occur when the end of the
file is reached.
llvm-svn: 226603
The test was fixed after a discussion with the revision author: the check
pattern was made more flexible as the "%call" part is not what we actually want
to check strictly there.
The original patch description:
===
Introduce SPIR calling conventions.
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
===
llvm-svn: 226561
This implements Section 3.7 from the SPIR 1.2 spec:
SPIR kernels should use "spir_kernel" calling convention.
Non-kernel functions use "spir_func" calling convention. All
other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
llvm-svn: 226548
Analogous to AVX2, these need to be implemented as macros to properly
propagate the immediate index operand.
Part of <rdar://problem/17688758>
llvm-svn: 226496
Emacs functions by default use character positions; convert characters
to offsets when handing parameters to clang-format and convert byte
offsets we get from clang-format back to character positions.
Reworked the code a bit so the 0-based to 1-based offset calculations
are done in the same place where we do the multi-byte to offset mapping.
llvm-svn: 226445
Things that are OK:
extern int var1 __attribute((alias("v1")));
static int var2 __attribute((alias("v2")));
Things that are not OK:
int var3 __attribute((alias("v3")));
extern int var4 __attribute((alias("v4"))) = 4;
We choose to accpet:
struct S { static int var5 __attribute((alias("v5"))); };
This code causes assertion failues in GCC 4.8 and ICC 13.0.1, we have
no reason to reject it.
This partially fixes PR22217.
llvm-svn: 226436
If an unscoped enum is used as a nested name specifier and the language dialect
is not C++ 11, issue an extension warning.
This fixes PR16951.
Differential Revision: http://reviews.llvm.org/D6389
llvm-svn: 226413
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
The code setting the debug location being removed here was accidentally
leaking a location into the call to the non-static data member's ctor
call. Without it the call had no location and could cause assertion
failures if it was inlined. Now that it has a location (and a correct
one at that) this code should hopefully be no longer needed.
It's possible of course that other parts of the debug info are also
relying on the debug locations being set here to leak to where they're
needed - so we might see the same assertions again & will have to
investigate what the dependence was/is. But the chances are good that
any of those are debug info line table quality bugs we've just not found
yet anyway - so it'll be good to flush them out.
llvm-svn: 226383
This was causing some trouble for otherwise dead code removed in r225085
(reverted in r225361). The location being set for function arguments was
leaking out to the call which wasn't setting its own location (so a
quality bug turned into a crasher with r225085). Fix this so r225085 can
be recommitted.
llvm-svn: 226382
logic.
In one place we would try to check for the difference between integers
even if we were missing one of the integers. This would eventually end
up reading uninitialized data out of the APSInt objects. The fix is to
short circuit the sameness test when we don't have integers on both
sides.
This fixes a test failure I was seeing with MSan. Not sure whether other
bots were seeing it or not, but yay MSan. In particular the feature to
very carefully track origins back through stores throughout the program
was invaluable.
llvm-svn: 226375
Clang currently crashes on
class C {
C() = default;
C() = delete;
};
My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid. This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.
This also improves error messages when functions are redeclared.
llvm-svn: 226365
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
As mentioned in the previous commit, if a property (declared with @property)
has a name that matches a special Objective-C method family, the getter picks
up that family despite being declared by the property. The most correct way
to solve this problem is to add the 'objc_method_family' attribute to the
getter with an argument of 'none', which unfortunately requires an explicit
declaration of the getter.
This commit adds a note to the existing error (ARC) or warning (MRR) for
such a poorly-named property that suggests the solution; if there's already
a declaration of the getter, it even includes a fix-it.
llvm-svn: 226339
Two years ago I added a compile-time "optimization" to
ObjCMethodDecl::findPropertyDecl: exit early if the current method is part
of a special Objective-C method family (like 'new' or 'init'). However, if a
property (declared with @property) has a name that matches a method family,
the getter picks up that family despite being declared by the property. The
early exit then made ObjCMethodDecl::findPropertyDecl decide that there
was no associated property, despite the method itself being marked as an
accessor. This corrects that by removing the early exit.
This does /not/ change the fact that such a getter is considered to return a
value with a +1 retain count. The best way to eliminate this is by adding the
objc_method_family(none) attribute to the getter, but unlike the existing
ns_returns_not_retained that can't be applied directly to the property -- you
have to redeclare the getter instead.
(It'd be nice if @property just implied objc_method_family(none) for its
getter, but that would be a backwards-incompatible change.)
rdar://problem/19038838
llvm-svn: 226338
Emitting inlinable calls without debug locations (in functions with
debug info, to functions with debug info) is problematic for debug info
when inlining occurs. Test specifically that we don't do that in this
case - thus the test isn't simply "don't crash", it's "include debug
location for this call" (granted it's the wrong location - fix for that
is coming)
llvm-svn: 226337
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
llvm-svn: 226334
There was already an explicit check for that for the first decl. Move that
to a different place so that it's called for the following decls too. Also
don't randomly set the BitfieldSize ExprResult to true (this sets a pointer to
true internally).
Found by SLi's bot.
llvm-svn: 226306
storage.
This fix allows to use non-constant global variables, static local variables and static data
members in data-sharing attribute clauses in parallel and task regions.
llvm-svn: 226250
This produces comdats for vtables, typeinfo, typeinfo names, and vtts.
When combined with llvm not producing implicit comdats, not doing this would
cause code bloat on ELF and link errors on COFF.
llvm-svn: 226227
The PPC backend will now assume that PPC64 ELFv1 function descriptors are
invariant. This must be true for well-defined C/C++ code, but I'm providing an
option to disable this assumption in case someone's JIT-engine needs it.
llvm-svn: 226209
Clang would previously become confused and crash here.
It does not make a lot of sense to export these, so warning seems appropriate.
MSVC will export some member functions for this kind of specializations, whereas
MinGW ignores the dllexport-edness. The latter behaviour seems better.
Differential Revision: http://reviews.llvm.org/D6984
llvm-svn: 226208
object from the pass that provides access to it.
We should probably refactor the createTLI code here in Clang in light of
the new structure, but I wanted this patch to be a minimal one that just
patches the behavior back together.
llvm-svn: 226158
Types composed with certain implicit record types would have their RTTI
marked as hidden because the implicit record type didn't have any
visibility.
This manifests itself as triggering false positives from tools like
clang's -fsantize=function feature. The RTTI for a function type's
return type wouldn't match if the return type was an implicit record
type.
Patch by Stephan Bergmann!
llvm-svn: 226148
Sema calls HandleVTable() with a bool parameter which is then threaded through
three layers. The only effect of this bool is an early return at the last
layer.
Instead, remove this parameter and call HandleVTable() only if the bool is
true. No intended behavior change.
llvm-svn: 226096
prior visible declaration. Prefer to take template parameter names from the
first declaration.
Testcase from a patch by Francisco Lopes!
llvm-svn: 226083
Summary:
This is a more robust way of figuring out implicit deployment target
from isysroot. It also handles iphone simulator target.
Reviewers: bob.wilson, t.p.northover
Reviewed By: t.p.northover
Subscribers: t.p.northover, cfe-commits
Differential Revision: http://reviews.llvm.org/D6939
llvm-svn: 226005
Summary:
This fixes MultiSource/Applications/lemon on big-endian N32 by correcting the
handling of the argument to wait(). glibc defines it as a transparent union of
void* and int*. Such unions are passed according to the rules of the first
member so the argument must be passed as if it were a void* (sign extended from
i32 to i64) and not as a union (shifted to the upper bits of an i64).
wait() already behaves correctly on big-endian O32 and N64 since the union is
already the same size as an argument slot.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6963
llvm-svn: 225981
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
llvm-svn: 225979
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
Without setting the CurEHLocation these cleanups would be attributed to
whatever the last active debug line location was (the 'fn' call in the
included test cases). By setting CurEHLocation correctly the line
information is improved/corrected.
This quality bug turned into a crasher with r225000 when, instead of
allowing the last location to persist, it would be zero'd out. This
could lead to a function call (such as the dtor) being made without a
debug location - if that call was subsequently inlined (and the caller
and callee had debug info, just not the call instruction) the inliner
would violate important constraints about the debug location chains by
not updating the inlined instructions to chain up to the callee
locations.
So, by fixing this bug, I am addressing the assertion failures
introduced by r225000 and should be able to recommit that patch with
impunity...
llvm-svn: 225955
We would check the type information from the declaration found by lookup
but we would neglect checking compatibility with the most recent
declaration. This would make it possible for us to not correctly
diagnose inconsistencies with declarations which were made in a
different scope.
llvm-svn: 225934
These are implemented with __builtin_shufflevector just like AVX.
We have some tests on the LLVM side to assert that these shufflevectors do
indeed generate the corresponding unpck instruction.
Part of <rdar://problem/17688758>
llvm-svn: 225922
A pass that adds random noops to X86 binaries to introduce diversity with the goal of increasing security against most return-oriented programming attacks.
Command line options:
-noop-insertion // Enable noop insertion.
-noop-insertion-percentage=X // X% of assembly instructions will have a noop prepended (default: 50%, requires -noop-insertion)
-max-noops-per-instruction=X // Randomly generate X noops per instruction. ie. roll the dice X times with probability set above (default: 1). This doesn't guarantee X noop instructions.
In addition, the following 'quick switch' in clang enables basic diversity using default settings (currently: noop insertion and schedule randomization; it is intended to be extended in the future).
-fdiversify
This is the clang part of the patch.
llvm part: D3392
http://reviews.llvm.org/D3393
Patch by Stephen Crane (@rinon)
llvm-svn: 225910
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
This is a different approach to r225780.
llvm-svn: 225875
This was previously piggybacking on whatever happened to be the last
location set on CGDebugInfo/DIBuilder, which was wrong (it was often the
current location, such as the 'fn()' call site, not the end of the
block). With my improvements to set/unset the location in a scoped
manner (r225000) this went from a bad quality situation, to a crash.
Fixing this goes part-way to unblocking the recommit of r225000.
It's likely that any call to CodeGenFunction::StartFunction without the
CurEHLocation set represents a similar bug or risk of a bug. Perhaps
there are some callers that know they won't generate EH cleanups, but
I'm not sure.
I considered a generic catch-fix in StartFunction (just fallback to the
GlobalDecl's location) but that seemed like it'd mask bugs where the EH
location shouldn't be the same as the decl's location (& indeed by not
using that stop-gap I found this bug). We'll see how long I can hold out
on the generic catch-all. I might eventually be able to add an assertion
in.
llvm-svn: 225845
conflicting attribute, warn about the conflict and pick a "winning"
attribute to preserve, instead of emitting an error. This matches the
behavior when the conflicting attributes are on different declarations.
Along the way I discovered that conflicts involving __forceinline were
reported as 'always_inline' (alternate spelling, same attribute) so
fixed that up to report the attribute as spelled in the source.
llvm-svn: 225813
If a module map contains
framework module * [extern_c] {}
We will now infer [extern_c] on the inferred framework modules (we
already inferred [system] as a special case).
llvm-svn: 225803
I'm not sure why we have OS.indent(Indent+2) for the system attribute,
but presumably we want the same behaviour for all attributes...
llvm-svn: 225802
Summary:
The Mips ABI's treat pointers in the same way as integers. They are
sign-extended to 32-bit for O32, and 64-bit for N32/N64. This doesn't matter
for O32 and N64 where pointers are already the correct width but it does matter
for big-endian N32, where pointers are 32-bit and need promoting.
The caller side is already passing pointers correctly. This patch corrects the
callee.
Reviewers: vmedic, atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6812
llvm-svn: 225782
In the following:
void f(int x) { extern int x; }
The second declaration of 'x' shouldn't be considered a redeclaration of
the parameter.
llvm-svn: 225780
The EOF token injection technique is preferable to using
isBeforeInTranslationUnit to determine whether or not additional cleanup
is needed. I don't have an example off-hand that requires it but it is
nicer nonetheless.
llvm-svn: 225776
We'd crash trying to make the SourceRange for the tokens we'd like to
highlight. Don't assume there is more than one token makes up the
default argument.
llvm-svn: 225774
Mark the end of the method body with an EOF token, collect it once we
expect to be done with method body parsing. No functionality change
intended.
llvm-svn: 225765
There are two things in a C++ program that need to read the vtable pointer:
Constructors and destructors. (A few other operations -- virtual calls,
dynamic cast, rtti -- read the vtable pointer off a this pointer, but for
this they don't need the vtable symbol.) Implicit constructors and destructors
and explicit constructors already marked the vtable as used, but explicit
destructors didn't.
Note that the only thing sema's "mark a class's vtable used" does is to mark all
final overriders of the class as referenced, it does _not_ cause emission of
the vtable itself. This is done on demand by codegen, independent of sema,
since sema might emit functions that are not referenced. (The exception are
vtables that are forced via key functions -- these are forced onto codegen
by sema.)
This bug went unnoticed for years because it doesn't have observable effects
(yet -- I want to change this in PR20337, which is why I noticed this).
r213109 made it so that _calls_ to constructors don't mark the vtable used.
Currently, _calls_ to destructors still mark the vtable used. If that
wasn't the case, this program would tickle the problem:
test.h:
template <typename T>
struct B {
int* p;
virtual ~B() { delete p; }
virtual void f() {}
};
struct __attribute__((visibility("default"))) C {
C();
B<int> m;
};
test2.cc:
#include "test.h"
int main() {
C* c = new C;
delete c;
}
test3.cc:
#include "test.h"
C::C() {}
# This bin/clang++ binary doesn't MarkVTableUsed() for virtual dtor calls:
$ bin/clang++ -shared test3.cc -std=c++11 -O2 -fvisibility=hidden \
-fvisibility-inlines-hidden -o libtest3.dylib
$ bin/clang++ test2.cc -std=c++11 -O2 -fvisibility=hidden \
-fvisibility-inlines-hidden libtest3.dylib
Undefined symbols for architecture x86_64:
"B<int>::f()", referenced from:
vtable for B<int> in test2-af8f4f.o
ld: symbol(s) not found for architecture x86_64
What's happening here is that there's a copy of B's vtable hidden in
libtest3.dylib, because C's constructor caused an implicit instantiation of that
(and implicit constructors generate vtables).
test2.cc calls C's destructDr, which destroys the B<int> member,
which wants to overwrite the vtable back to B (think of B as the base of a class
hierarchy, and of hierarchical destruction -- maybe we shouldn't do the vtable
writing in destructors of final classes), but there's nothing in test2.cc that
marks B's vtable used. So codegen writes out the vtable, but since it wasn't
marked used, sema didn't mark all the virtual functions (in particular f())
as used.
Note that this change makes us reject programs we didn't reject before (see
the included Sema test case), but both gcc and cl also reject this code, and
clang used to reject it before r213109.
llvm-svn: 225761
even though every basic source character literal has the same numerical value
as a narrow or wide character literal.
It appears that the FreeBSD folks are trying to use this macro to mean
something other than what the relevant standards say it means, but their usage
is conforming, so put up with it.
llvm-svn: 225751
Templates don't have key functions (cf computeKeyFunction() in
RecordLayoutBuilder.cpp), so don't have something that looks like one.
Also, instead of a vcall to force generation of the vtable, just construct
the object. This is how the repro on PR5557 (what the test is for) worked too.
llvm-svn: 225741
Introduce the following -fsanitize-recover flags:
- -fsanitize-recover=<list>: Enable recovery for selected checks or
group of checks. It is forbidden to explicitly list unrecoverable
sanitizers here (that is, "address", "unreachable", "return").
- -fno-sanitize-recover=<list>: Disable recovery for selected checks or
group of checks.
- -f(no-)?sanitize-recover is now a synonym for
-f(no-)?sanitize-recover=undefined,integer and will soon be deprecated.
These flags are parsed left to right, and mask of "recoverable"
sanitizer is updated accordingly, much like what we do for -fsanitize= flags.
-fsanitize= and -fsanitize-recover= flag families are independent.
CodeGen change: If there is a single UBSan handler function, responsible
for implementing multiple checks, which have different recoverable setting,
then we emit two handler calls instead of one:
the first one for the set of "unrecoverable" checks, another one - for
set of "recoverable" checks. If all checks implemented by a handler have the
same recoverability setting, then the generated code will be the same.
llvm-svn: 225719
The llvm IR until recently had no support for comdats. This was a problem when
targeting C++ on ELF/COFF as just using weak linkage would cause quite a bit of
dead bits to remain on the executable (unless -ffunction-sections,
-fdata-sections and --gc-sections were used).
To fix the problem, llvm's codegen will just assume that any weak or linkonce
that is not in an explicit comdat should be output in one with the same name as
the global.
This unfortunately breaks cases like pr19848 where a weak symbol is not
xpected to be part of any comdat.
Now that we have explicit comdats in the IR, we can finally get both cases
right.
This first patch just makes clang give explicit comdats to GlobalValues where
t is allowed to.
A followup patch to llvm will then stop implicitly producing comdats.
llvm-svn: 225705
This just tweaks the fix from r224892 (which handled PCHs) to work with
modules, where we will serialize each method individually and hence the
hasMoreThanOneDecl bit needs to be updated as we add the methods.
llvm-svn: 225659
Specifically, adjust the leading "__asm {" and trailing "}" while still
leaving the assembly inside it alone.
This fixes llvm.org/PR22190.
llvm-svn: 225623
Similar to r225619, use a special EOF token to mark the end of the
exception specification instead of cxx_exceptspec_end. Use the current
scope as the marker.
llvm-svn: 225622
Alexey Bataev