| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces the -fsanitize=cfi-vptr flag, which enables a control
flow integrity scheme that checks that virtual calls take place using a vptr of
the correct dynamic type. More details in the new docs/ControlFlowIntegrity.rst
file.
It also introduces the -fsanitize=cfi flag, which is currently a synonym for
-fsanitize=cfi-vptr, but will eventually cover all CFI checks implemented
in Clang.
Differential Revision: http://reviews.llvm.org/D7424
llvm-svn: 230055
|
| |
|
|
|
|
| |
documentation in r229818.
llvm-svn: 229950
|
| |
|
|
|
|
|
|
|
| |
MinGW neither imports nor exports such methods. The import bit was
committed earlier, in r221154, and this takes care of the export part.
This also partially fixes PR22591.
llvm-svn: 229922
|
| |
|
|
| |
llvm-svn: 229918
|
| |
|
|
| |
llvm-svn: 229915
|
| |
|
|
|
|
| |
Fixes PR22635.
llvm-svn: 229913
|
| |
|
|
| |
llvm-svn: 229902
|
| |
|
|
|
|
|
|
|
| |
Classes can be defined in multiple translation units. This means that
the static constexpr data members should have identical initializers in
all translation units. Implement this by giving the reference temporary
linkonce_odr linkage.
llvm-svn: 229900
|
| |
|
|
| |
llvm-svn: 229812
|
| |
|
|
|
|
|
| |
We didn't have enough qualificaiton before the scope specifier and we
had too much qualification in the destructor name itself.
llvm-svn: 229809
|
| |
|
|
| |
llvm-svn: 229725
|
| |
|
|
|
|
|
|
|
| |
extern "C" declarations should be considered like global declarations
for mangling purposes.
Differential Revision: http://reviews.llvm.org/D7718
llvm-svn: 229724
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D7148
llvm-svn: 229680
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We attempted to be compatible with GCC's buggy mangling for templates
with a declaration for a template argument.
However, we weren't completely successful in copying their bug in cases
like:
char foo;
template <char &C> decltype(C) f() { return foo; };
template char &f<foo>();
Instead, just follow the ABI specification. This fixes PR22621.
llvm-svn: 229644
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Our mangling of <destructor-name> wasn't quite right: we'd introduce
mangling substitutions where one shouldn't be possible. We also didn't
correctly handle the case where the destroyed type was not dependent but
still a TemplateSpecializationType.
N.B. There isn't a mangling for a template-template parameter showing up
as the destroyed type. We do the 'obvious' thing and mangle the index
of the parameter.
llvm-svn: 229615
|
| |
|
|
|
|
| |
-fdefine-sized-deallocation, and from DefaultSizedDelete to DefineSizedDeallocation.
llvm-svn: 229597
|
| |
|
|
| |
llvm-svn: 229291
|
| |
|
|
| |
llvm-svn: 229270
|
| |
|
|
| |
llvm-svn: 229269
|
| |
|
|
|
|
|
|
|
|
| |
We had two bugs:
- We were missing the "on" prefix for unresolved operators.
- We didn't handle the mangling of destructors at all.
This fixes PR22584.
llvm-svn: 229255
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
they're given a null pointer as an argument, so we do not need to emit null
checks on their results.
llvm-svn: 229213
|
| |
|
|
|
|
|
| |
LLVM doesn't support non-call exceptions, so inlining makes it harder to
catch such asynchronous exceptions.
llvm-svn: 228876
|
| |
|
|
| |
llvm-svn: 228863
|
| |
|
|
|
|
|
| |
Disabling exceptions applies nounwind to lots of functions. SEH catches
asynch exceptions, so emit the landing pad anyway.
llvm-svn: 228769
|
| |
|
|
| |
llvm-svn: 228589
|
| |
|
|
|
|
|
|
| |
Matches the existing code for scalar default arguments. Complex default
arguments probably need the same handling too (test/fix to that coming
next).
llvm-svn: 228588
|
| |
|
|
|
|
|
|
|
|
|
| |
After r228258, Clang started emitting C++ EH IR that LLVM wasn't ready
to deal with, even when exceptions were disabled with /EHs-. This time,
make /EHs- turn off -fexceptions while still emitting exceptional
constructs in functions using __try. Since Sema rejects C++ exception
handling constructs before CodeGen, landingpads should only appear in
such functions as the result of a __try.
llvm-svn: 228329
|
| |
|
|
|
|
|
|
|
|
| |
initializer of the form {x}, where x is of type C or a type derived from C,
perform *non-list* initialization of the entity from x, but create a
CXXConstructExpr that knows that we used list-initialization syntax.
Plus some fixes to ensure we mangle correctly in this and related cases.
llvm-svn: 228276
|
| |
|
|
| |
llvm-svn: 228274
|
| |
|
|
|
|
|
|
|
| |
It caused a chromium base unittest that tests throwing and catching SEH
exceptions to fail (http://crbug.com/455488) and I suspect it might also
be the cause of the chromium clang win 64-bit shared release builder timing
out during compiles. So revert to see if that's true.
llvm-svn: 228262
|
| |
|
|
|
|
|
|
|
|
|
|
| |
CHECK: call {{.*}}src
matched
%call = invoke dereferenceable(4) i32* @_Z3srcv()
I don't think it was intentional.
llvm-svn: 228245
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 228146
|
| |
|
|
| |
llvm-svn: 228111
|
| |
|
|
| |
llvm-svn: 228110
|
| |
|
|
| |
llvm-svn: 228108
|
| |
|
|
|
|
| |
visibility.
llvm-svn: 228107
|
| |
|
|
|
|
|
|
| |
explicit triple x86_64-unknown.
It seems incompatible to i686.
llvm-svn: 228100
|
| |
|
|
| |
llvm-svn: 228099
|
| |
|
|
| |
llvm-svn: 228098
|
| |
|
|
| |
llvm-svn: 228088
|
| |
|
|
| |
llvm-svn: 228066
|
| |
|
|
| |
llvm-svn: 228065
|
| |
|
|
|
|
|
|
| |
We would synthesize memcpy intrinsics when emitting calls to trivial C++
constructors but we wouldn't take into account the alignment of the
destination.
llvm-svn: 228061
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are four major kinds of declarations that cause code generation:
- FunctionDecl (includes CXXMethodDecl etc)
- ObjCMethodDecl
- BlockDecl
- CapturedDecl
This patch tracks __try usage on FunctionDecls and diagnoses __try usage
in other decls. If someone wants to use __try from ObjC, they can use it
from a free function, since the ObjC code will need an ObjC-style EH
personality.
Eventually we will want to look through CapturedDecls and track SEH
usage on the parent FunctionDecl, if present.
llvm-svn: 228058
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
have default arguments, still have locations.
To handle default arguments in C++ in the debug info, we disable code
updating the debug location during the emission of default arguments.
This code was buggy in the case of default arguments which, themselves,
have default arguments - the inner default argument would re-enable
debug info when it was finished, but before the outer default argument
was finished.
This was already a bug, but got worse (because a crasher instead of just
a quality bug) with the recent improvements to debug info line quality
because... The ApplyDebugLocation scoped device would find the debug
info disabled and not save any debug location. But then in
~ApplyDebugLocation it would find the debug info had been enabled and
would then apply the no-location. Then the outer function call would be
emitted without any location. That's bad.
Arguably we could /also/ fix the ApplyDebugLocation to assert on this
situation (where debug info was disabled in the ctor and enabled in the
dtor, or the other way around) but this is at least the necessary fix
regardless.
(also, I imagine this disabling behavior might need to be in-place for
CGExprComplex and CGExprAgg too, maybe... ?)
And I seem to recall seeing some weird default arg stepping behavior
recently which might be related to this too... I'll have to look into
it.
llvm-svn: 228053
|
| |
|
|
| |
llvm-svn: 227838
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang currently calls MarkVTableUsed() for classes that get their virtual
methods called or that participate in a dynamic_cast. This is unnecessary,
since CodeGen only emits vtables when it generates constructor, destructor, and
vtt code. (*)
Note that Sema::MarkVTableUsed() doesn't cause the emission of a vtable.
Its main user-visible effect is that it instantiates virtual member functions
of template classes, to make sure that if codegen decides to write a vtable
all the entries in the vtable are defined.
While this shouldn't change the behavior of codegen (other than being faster),
it does make clang more permissive: virtual methods of templates (in particular
destructors) end up being instantiated less often. In particular, classes that
have members that are smart pointers to incomplete types will now get their
implicit virtual destructor instantiated less frequently. For example, this
used to not compile but does now compile:
template <typename T> struct OwnPtr {
~OwnPtr() { static_assert((sizeof(T) > 0), "TypeMustBeComplete"); }
};
class ScriptLoader;
struct Base { virtual ~Base(); };
struct Sub : public Base {
virtual void someFun() const {}
OwnPtr<ScriptLoader> m_loader;
};
void f(Sub *s) { s->someFun(); }
The more permissive behavior matches both gcc (where this is not often
observable, since in practice most things with virtual methods have a key
function, and Sema::DefineUsedVTables() skips vtables for classes with key
functions) and cl (which is my motivation for this change) – this fixes
PR20337. See this issue and the review thread for some discussions about
optimizations.
This is similar to r213109 in spirit. r225761 was a prerequisite for this
change.
Various tests relied on "a->f()" marking a's vtable as used (in the sema
sense), switch these to just construct a on the stack. This forces
instantiation of the implicit constructor, which will mark the vtable as used.
(*) The exception is -fapple-kext mode: In this mode, qualified calls to
virtual functions (`a->Base::f()`) still go through the vtable, and since the
vtable pointer off this doesn't point to Base's vtable, this needs to reference
Base's vtable directly. To keep this working, keep referencing the vtable for
virtual calls in apple kext mode.
llvm-svn: 227073
|