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
I added setEofData/getEofData to solve this sort of problem back in
r224505. Use the Param's decl to tell us if this is *our* EOF token.
llvm-svn: 225619
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
end iterator for iterator_range<>. I removed this constructor because
for some iterators (notably pointers) it left begin and end
uninitialized. It also is an usual constraint that an iterator default
constructs to a valid end iterator such that the pair of them for
a valid range. In the three places where this was used in Clang,
explicitly build the empty range from the iterators and comment on why
default constructed iterators make sense here.
llvm-svn: 225594
-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
Paul Robinson