| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Register are thread-local by default, so we have to consider them as threadprivate.
llvm-svn: 225759
|
| |
|
|
|
|
|
| |
Move the logic for checking self moves into SemaChecking and add that function
to Sema since it is now used in multiple places.
llvm-svn: 225756
|
| |
|
|
|
|
| |
the tokens around so we can diagnose an error rather than silently discarding them.
llvm-svn: 225755
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 225684
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to the Alitivec support in clang. __bool is functionally identical to using bool when declaring vector types. For example:
vector bool char v_bc;
vector __bool char v___bc;
clang already supported vector/__vector and pixel/__pixel but was missing __bool.
http://llvm.org/bugs/show_bug.cgi?id=19220
For reference: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html
http://reviews.llvm.org/D6882
llvm-svn: 225664
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
This doesn't fail on "env clang". Investigating.
llvm-svn: 225626
|
| |
|
|
| |
llvm-svn: 225616
|
| |
|
|
|
|
|
|
| |
It is not correct to let it consume the cxx_defaultarg_end token. I'm
starting to wonder if it makes more sense to stop SkipUntil from
consuming such tokens.
llvm-svn: 225615
|
| |
|
|
|
|
|
|
| |
The rewrite map files are not copied, and so cannot be tracked as temporary
files. Add them explicitly to the list of files that we request from the user
to be attached to bug reports.
llvm-svn: 225614
|
| |
|
|
|
|
|
|
| |
Recovery from malformed lambda introducers would find us consuming the
synthetic default argument token, which is bad. Instead, stop right
before that token.
llvm-svn: 225613
|
| |
|
|
|
|
|
| |
Clang would treat the digits in an "11m" input constraint separately as
if it was handling constraint 1 twice instead of constraint 11.
llvm-svn: 225606
|
| |
|
|
|
|
|
|
|
| |
Input constraints like "0" and "[foo]" should be treated the same when
it comes to their corresponding output constraint.
This fixes PR21850.
llvm-svn: 225605
|
| |
|
|
| |
llvm-svn: 225603
|
| |
|
|
|
|
| |
LLVM the consecutive '%' modifiers are redundant, skip them.
llvm-svn: 225602
|
| |
|
|
|
|
| |
LLVM the consecutive '&' modifiers are redundant, skip them.
llvm-svn: 225601
|
| |
|
|
| |
llvm-svn: 225600
|
| |
|
|
| |
llvm-svn: 225587
|
| |
|
|
|
|
| |
Don't permit '+&m' to make it to CodeGen, it's invalid.
llvm-svn: 225586
|
| |
|
|
|
|
|
|
| |
-Wself-move is similiar to -Wself-assign. This warning is triggered when
a value is attempted to be moved to itself. See r221008 for a bug that
would have been caught with this warning.
llvm-svn: 225581
|
| |
|
|
|
|
| |
cast notation T{...} when T is a reference type.
llvm-svn: 225571
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Their linkage can change if they are later explicitly instantiated. We would
previously emit such functions eagerly (as opposed to lazily on first use) if
they have a 'dllexport' or 'used' attribute, and fail an assert when hitting the
explicit instantiation.
This is achieved by replacing the old CodeGenModule::MayDeferGeneration() method
with two new ones: MustBeEmitted() and MayBeEmittedEagerly().
Differential Revision: http://reviews.llvm.org/D6674
llvm-svn: 225570
|
| |
|
|
| |
llvm-svn: 225561
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
It's not safe to blindly call getIdentifierInfo without checking the
token is not an annotation token.
llvm-svn: 225533
|
| |
|
|
|
|
|
|
| |
It seemed odd to have to make DefaultImageName be a mutable member of Driver.
We don't need to the full result of computeTargetTriple() to determine the
image name; just base it on DefaultTargetTriple.
llvm-svn: 225530
|
| |
|
|
|
|
|
|
|
| |
We have a diagnostic describing that constexpr changed in C++14 when
compiling in C++11 mode. While doing this, it examines the previous
declaration and assumes that it is a function. However it is possible,
in the context of error recovery, for this to not be the case.
llvm-svn: 225518
|
| |
|
|
|
|
| |
(I should have re-run the test after running clang-format)
llvm-svn: 225515
|
| |
|
|
|
|
|
|
|
|
|
| |
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
llvm-svn: 225514
|
| |
|
|
| |
llvm-svn: 225513
|
| |
|
|
|
|
|
| |
RecordDecls should have things like CXXMethodDecls or FriendDecls as a
decl but not things like FunctionDecls.
llvm-svn: 225511
|
| |
|
|
|
|
|
|
| |
We assumed that class-scope specializations would result in a
CXXMethodDecl for that class. However, globally qualified functions
will result in normal FunctionDecls.
llvm-svn: 225508
|
| |
|
|
|
|
|
|
|
| |
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.
This fixes PR22122.
llvm-svn: 225505
|
| |
|
|
|
|
|
|
|
|
| |
Allow blessed access to the symbol rewriter from the driver. Although the
symbol rewriter could be invoked through tools like opt and llc, it would not
accessible from the frontend. This allows us to read the rewrite map files in
the frontend rather than the backend and enable symbol rewriting for actually
performing the symbol interpositioning.
llvm-svn: 225504
|
| |
|
|
|
|
|
|
|
| |
We were previously emitting counter increments even if we didn't have
an insertion point, which would result in a CallInst with no
parent. This leads to a crash, as in pr22166, if we try to do
GlobalDCE.
llvm-svn: 225495
|
| |
|
|
|
|
|
|
|
|
|
| |
We forgot to mark designated initializer expression that contain type
dependent array designators as type dependent. This would lead to
crashes when we try to determine which array element we were trying to
initialize.
This fixes PR22056.
llvm-svn: 225494
|
| |
|
|
|
|
|
|
|
|
| |
we're instantiating, if there's a ParmVarDecl within a FunctionDecl context
that is not a parameter of that function. Add some asserts to catch this kind
of issue more generally, and fix another bug exposed by those asserts where we
were missing a local instantiation scope around substitution of
explicitly-specified template arguments.
llvm-svn: 225490
|
| |
|
|
|
|
|
|
|
| |
better than the 'template-parameter-x-y' name that we'd get in AST printing,
and is worse in several ways (it's harder to distinguish it from a
user-supplied name, it's wrong after substituting some number of outer
levels, it wastes time and space constructing an IdentifierInfo, ...).
llvm-svn: 225489
|
| |
|
|
|
|
| |
may have different sizes. Fixes PR22017
llvm-svn: 225488
|
| |
|
|
|
|
|
|
|
| |
Update testcases for LLVM change in r225474 to make `MDNode`s explicitly
distinct (when they aren't uniqued).
Part of PR22111.
llvm-svn: 225475
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there are some non-ascii character in the input source code, the
column index might be smallar than the byte index. This will result
in two possible assertion failures. This CL fixes the computation of
the column index and byte index.
1. The assertion in startOfNextColumn() and startOfPreviousColumn()
should not be raised when the byte index is greater than the column
index since the non-ascii characters may use more than one bytes to
store a character in a column.
2. The length of the caret line should be equal to the number of columns
of source line, instead of the length of the source line. Otherwise,
the assertion in selectInterestingSourceRegion will be raised because
the removed columns plus the kept columns are not greater than the max
column, which means that we should not remove any column at all.
llvm-svn: 225442
|
| |
|
|
| |
llvm-svn: 225426
|
| |
|
|
|
|
| |
unprintable characters. Fixes PR22048.
llvm-svn: 225423
|
| |
|
|
|
|
|
|
|
|
|
|
| |
transform.
Also diagnose typos in the initializer of an invalid C++ declaration.
Both issues were hit using the same line of test code, depending on
whether the code was treated as C or C++.
Fixes PR22092.
llvm-svn: 225389
|
| |
|
|
|
|
|
|
| |
Shorter and doesn't need -O2 -- but still suboptimal as it's still doing
-emit-obj. dblaikie says he'll improve this when he'll reland his change
with a fix.
llvm-svn: 225364
|