The member gets invalidated as elements are added to the dense set. Directly
access the underlying pointer instead. Not sure how to create a test case for
this :-(. Maybe Richard can help.
llvm-svn: 229673
Add some of the missing M and R class Cortex CPUs, namely:
Cortex-M0+ (called Cortex-M0plus for GCC compatibility)
Cortex-M1
SC000
SC300
Cortex-R5
llvm-svn: 229661
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
The motivation is to fix a crash on
struct S {} s;
Foo S::~S() { s.~S(); }
What was happening here was that S::~S() was marked as invalid since its
return type is invalid, and as a consequence CheckFunctionDeclaration() wasn't
called and S::~S() didn't get merged into S's implicit destructor. This way,
the class ended up with two destructors, which confused the overload printer
when it suddenly had to print two possible destructors for `s.~S()`.
In addition to fixing the crash, this change also seems to improve diagnostics
in a few other places, see test changes.
Crash found by SLi's bot.
llvm-svn: 229639
Un-parameterize the warning as there is exactly one attribute added in C++14.
Partially addresses post-commit review comments from Richard Smith.
llvm-svn: 229636
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
This fixes PR22492, which is in response to CWG issue #1204.
Per the CWG issue 'contexpr' variables are now allowed in
for range loops.
llvm-svn: 229543
ParsePostfixExpressionSuffix() for '->' (or '.') postfixes first calls
ActOnStartCXXMemberReference() to inform sema that a member reference is about
to start, and that function lets the parser know if sema thinks that the
base expression's type could allow a pseudo destructor from a semantic point of
view (for example, if the the base expression has a dependent type).
ParsePostfixExpressionSuffix() then calls ParseOptionalCXXScopeSpecifier() and
passes MayBePseudoDestructor on to that function, expecting the function to
set it to false if a pseudo destructor is impossible from a syntactic point of
view (due to a lack of '~' sigil). However, ParseOptionalCXXScopeSpecifier()
had early-outs for ::new and __super, so MayBePseudoDestructor stayed true,
so we tried to parse a pseudo dtor, and then became confused since we couldn't
find a '~'. Move the snippet in ParseOptionalCXXScopeSpecifier() that sets
MayBePseudoDestructor to false above the early exits.
Parts of this found by SLi's bot.
llvm-svn: 229449
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
In the case that we diagnosed an invalid attribute due to missing or present
arguments, we would return false, indicating to the caller that the parsing
failed. However, we would have added the attribute in ParseAttributeArgsCommon
(which may have been called indirectly through ParseGNUAttributeArgs).
Returning true in this case ensures that a second copy of the attribute is not
added.
I haven't added a test case for this as the existing test will cover this with
the next commit which diagnoses a C++14 attribute applied in C++11 mode. Rather
than duplicating the existing test case, allow the tree to remain without a test
between this and the next change. We would see double warnings in the
[[deprecated()]] applied to a declaration in C++11 mode, which will cause an
error in the cxx0x-attributes test.
llvm-svn: 229446
This is a patch for PR22563 ( http://llvm.org/bugs/show_bug.cgi?id=22563 ).
We were not correctly unwrapping a single 256-bit AVX vector that was defined as an array of 1 inside a struct.
We would generate a <4 x float> param/return value instead of <8 x float> and lose half of the vector.
Differential Revision: http://reviews.llvm.org/D7614
llvm-svn: 229408
Bug report: http://llvm.org/bugs/show_bug.cgi?id=22561
Clang tries to create ObjCBoxedExpression of type 'NSNumber'
when 'NSNumber' has only forward declaration, this cause a crash later,
when 'Sema' refers to a nil QualType of the whole expression.
Please, refer to the bug report for the better explanation.
llvm-svn: 229402
For #pragma comment(linker, ...) MSVC expects the comment string to be quoted, but for #pragma comment(lib, ...) the compiler itself quotes the library name.
Since this distinction disappears by the time the directive reaches the backend, move quoting for the "lib" version to the frontend.
Differential Revision: http://reviews.llvm.org/D7653
llvm-svn: 229376
subobject initialization is not possible, be sure to note the overall
initialization as having failed so that overload resolution knows that the
relevant candidate is not viable.
llvm-svn: 229353
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229288
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
Bools are a little tricky, they are i8 in memory and must be coerced
back to i1 before further operations can be performed on them.
This fixes PR22577.
llvm-svn: 229204
declarations and just use the legacy namespace qualifier in this file
and the permanent header name.
The old wrapper header is going away to make LLVM's build more modular,
and without updating Clang I can't easily start to add usage of the new
pass manager to Clang. This should make it more clear in the code which
set of types is doing what.
llvm-svn: 229090
The /volatile:ms semantics turn volatile loads and stores into atomic
acquire and release operations. This distinction is important because
volatile memory operations do not form a happens-before relationship
with non-atomic memory. This means that a volatile store is not
sufficient for implementing a mutex unlock routine.
Differential Revision: http://reviews.llvm.org/D7580
llvm-svn: 229082
entity, put the originally-canonical decl IDs in the right places in the redecl
chain rather than reordering them all to the start. If we don't ensure that the
redecl chain order is consistent with the topological module order, we can fail
to make a declaration visible if later declarations are in more IDNSs than
earlier ones (for instance, because the earlier decls are invisible friends).
llvm-svn: 228978
When mangling the module map path into a .pcm file name, also mangle the
IsSystem bit, which can also depend on the header search paths. For
example, the user may change from -I to -isystem. This can affect
diagnostics in the importing TU.
llvm-svn: 228966
Partially revert r223927 because LLVM gained support for 128-bit integers
in r227089. Modify and keep the tests that verify the definition of the
macro __SIZEOF_INT128__ for MIPS64 BE & LE in the preprocessor.
llvm-svn: 228918
Summary:
This patch installs an InlineAsmDiagnosticsHandler to avoid the crash
report when the input is bitcode and the bitcode contains invalid inline
assembly. The handler will simply print the same error message that will
print from the backend.
Add CHECK in test-case
Reviewers: echristo, rafael
Reviewed By: rafael
Subscribers: rafael, cfe-commits
Differential Revision: http://reviews.llvm.org/D7568
llvm-svn: 228898
always use the normal copy-initialization rules. Remove a special case that
tries to stay within the list initialization checker here; that makes us do the
wrong thing when list-initialization of an aggregate would not perform
aggregate initialization.
llvm-svn: 228897
based on whether "redundant" braces are ever reasonable as part of the
initialization of the entity, rather than whether the initialization is
"top-level". In passing, add a warning flag for it.
llvm-svn: 228896
a non-uniqueable temporary node that is only turned into a permanent
unique or distinct node after it is finished.
Otherwise an intermediate node may get accidentally uniqued with another
node as illustrated by the testcase.
Paired commit with LLVM.
llvm-svn: 228855
(or of a lambda init-capture, which is sort-of such a variable). The semantics
of such constructs will change when we implement N3922, so we intend to warn on
this in Clang 3.6 then change the semantics in Clang 3.7.
llvm-svn: 228792
The state obtained from CheckerContext::getState() may be outdated by the time the alloc/dealloc handling function is called (e.g. the state was modified but the transition was not performed). State argument was added to all alloc/dealloc handling functions in order to get the latest state and to allow sequential calls to those functions.
llvm-svn: 228737
Somehow a check for aarch64 was added to the Darwin toolchain's
isKernelStatic function as part of the initial commit for Apple's
arm64 target (r205100). That check was not in any of Apple's internal
code and no one here knows where it came from. It has been harmless
because "-static" does not change much, if anything, for arm64 iOS code,
but it makes no sense to keep this check.
llvm-svn: 228673
already have, check whether the name from the module is actually newer than the
existing declaration. If it isn't, we might (say) replace a visible declaration
with an injected friend, and thus make it invisible (or lose a default argument
or an array bound).
llvm-svn: 228661
to the plist output. This check_name field does not guaranteed to be the
same as the name of the checker in the future.
Reviewer: Anna Zaks
Differential Revision: http://reviews.llvm.org/D6841
llvm-svn: 228624
Don't assume it will provide an error or null-terminate the string on
truncation, since POSIX doesn't guarantee either behaviour (although
Linux and Darwin at least will do the 'right thing').
llvm-svn: 228613
If the lock file manager times out, we should give an error rather than
silently trying to load the existing module. And delete the
(presumably) dead lock file, since it will otherwise prevent progress in
future invokations. This is unsound since we have no way to prove that
the lock file we are deleting is the same one we timed out on, but since
the lock is only to avoid excessive rebuilding anyway it should be okay.
Depends on llvm r228603.
llvm-svn: 228604
If gethostname() is not successful, just skip adding the hostname to the
module hash. And don't bother setting hostname[255] = 0, since if
gethostname() is successful, it will be null-terminated already (and if
it's not successful we don't read the string now.
llvm-svn: 228601
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
We'd give the VarDecl a CXXConstructExpr even though it is annotated
with an alias attribute. This would make us trip over sanity checking
asserts.
This fixes PR22493.
llvm-svn: 228523
This prevents contracting:
auto lambda = []() {
int a = 2
#if A
+ 2
#endif
;
};
into:
auto lambda = []() { int a = 2
#if A + 2
#endif ; };
Which is obviously BAD.
This fixes llvm.org/PR22496.
llvm-svn: 228522
It's slightly cheaper than copying it, if the DebugLoc points to replaceable
metadata every copy is recorded in a DenseMap, moving reduces the peak size of
that map.
llvm-svn: 228492
context as anonymous for merging purposes. They can't be found by their names,
so we merge them based on their position within the surrounding context.
llvm-svn: 228485
Before:
@try {
// ...
}
@finally {
// ...
}
Now:
@try {
// ...
} @finally {
// ...
}
This is consistent with how we format C++ try blocks and SEH try blocks.
clang-format not doing this before was an implementation oversight.
This is dependent on BraceBreakingStyle. The snippet above is with the
Attach style. Style Stroustrip for example still results in the "Before:"
snippet, which makes sense since other blocks (try, else) break after '}' too.
llvm-svn: 228483
Also removed unused builtins.
Original patch by Andrea Di Biagio!
Reviewers: craig.topper, nadav
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7199
llvm-svn: 228481
modifiers on them. If we have a matching output constraint with
an early clobber make sure we don't propagate that to the input
constraint.
llvm-svn: 228422
Summary:
-iframework option is used to specified System framework path so the
path specified should be passed to linker as -F option
rdar://problem/18234544
Reviewers: bob.wilson
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7106
llvm-svn: 228413
This reverts commit r228382.
This breaks the following case: Reported by Jeroen Ketema:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20150202/122961.html
typedef __attribute__((ext_vector_type(3))) char char3;
void foo() {
char3 v = {1,1,1};
char3 w = {1,2,3};
w <<= v;
}
If I compile with:
clang -x cl file.c
Then an error is produced:
file.c:10:5: error: expression is not assignable
w <<= v;
~ ^
1 error generated.
llvm-svn: 228406
Introduce a number of checks:
1. If LHS is a scalar, then RHS cannot be a vector.
2. Operands must be of integer type.
3. If both are vectors, then the number of elements must match.
Relax the requirement for "usual arithmetic conversions":
When LHS is a vector, a scalar RHS can simply be expanded into a
vector; OpenCL does not require that its rank be lower than the LHS.
For example, the following code is not an error even if the implicit
type of the constant literal is "int".
char2 foo(char2 v) { return v << 1; }
Consolidate existing tests under CodeGenOpenCL, and add more tests
under SemaOpenCL.
llvm-svn: 228382
of that entity, ensure that the redeclaration chain is reordered properly on
reload. Otherwise, the result of name lookup for that entity may point to an
entity that is too old; if that's an injected friend name or the like, that
can result in the name not being found at all.
llvm-svn: 228371
For compatibility with GCC (and because it's generally helpful information
otherwise inaccessible to the preprocessor). This appears to be canonically the
alignment of max_align_t (e.g. on i386, __BIGGEST_ALIGNMENT__ is 4 even though
vector types will be given greater alignment).
Patch mostly by Mats Petersson
llvm-svn: 228367
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
This patch emits the following code for the single directive:
#pragma omp single
<body>
<---->
if(__kmpc_single(...)) {
<body>
__kmpc_end_single(...);
}
Differential Revision: http://reviews.llvm.org/D7045
llvm-svn: 228275
For 'taskyield' directive emit call to kmp_int32 __kmpc_omp_taskyield(ident_t *,
kmp_int32 global_tid, int end_part); runtime function call with end_part arg set
to 0 (it is ignored).
Differential Revision: http://reviews.llvm.org/D7047
llvm-svn: 228272
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
In r227480, Ulrich Weigand introduced a workaround for a linker
optimization bug that can create mis-optimized code for accesses to
general-dynamic or local-dynamic TLS variables. The linker
optimization bug only occurred for Clang/LLVM because of some
inefficient code being generated for these TLS accesses. I have
recently corrected LLVM to produce the efficient code sequence
expected by the linkers, so this workaround is no longer needed.
Therefore this patch reverts r227480.
I've tested that the previous bootstrap failure no longer occurs with
the workaround reverted.
llvm-svn: 228253
The analyzer thinks that ArraySubscriptExpr cannot be an r-value (ever).
However, it can be in some corner cases. Specifically, C forbids expressions
of unqualified void type from being l-values.
Note, the analyzer will keep modeling the subscript expr as an l-value. The
analyzer should be treating void* as a char array
(https://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Pointer-Arith.html).
llvm-svn: 228249
Instead of handling edge cases (mostly involving blocks), where we have difficulty finding
an allocation statement, allow the allocation site to be in a parent node.
Previously we assumed that the allocation site can always be found in the same frame
as allocation, but there are scenarios in which an element is leaked in a child
frame but is allocated in the parent.
llvm-svn: 228247
Previously, we would use a frame pointer by default on non-Linux OSs. On
Linux, any optimization flags imply -fomit-frame-pointer. XCore always
defaulted to -fomit-frame-pointer.
Now x86 Windows matches our behavior on Linux. All other ISAs supported
by Windows (ARM, x64) use xdata information, and frame pointers aren't
useful. Frame pointers are now off by default for such targets, but can
be forced via -fno-omit-frame-pointer and code using alloca().
In fact, on Win64 our frame-pointer prologue is not describable with
UNWIND_INFO. This change is a workaround to avoid using the broken FP
using prologue for most functions. This is PR22467.
llvm-svn: 228236
object. In such a case, use the TU's DC for merging global decls rather than
giving up when we find there is no TU scope.
Ultimately, we should probably avoid all loading of decls when preprocessing,
but there are other reasonable use cases for loading an AST file with no Sema
object for which this is the right thing.
llvm-svn: 228234
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
When visiting AssignmentOps, keep evaluating after a failure (when possible) in
order to identify overflow in subexpressions.
Differential Revision: http://reviews.llvm.org/D1238
llvm-svn: 228202
std::lock_guard. If EXCLUSIVE_LOCKS_REQUIRED is placed on the constructor of
a SCOPED_LOCKABLE class, then that constructor is assumed to adopt the lock;
e.g. the lock must be held on construction, and will be released on destruction.
llvm-svn: 228194
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
A refinement of r204730, itself a refinement of r198953, to better handle
cases where an object is accessed both through a property getter and
through direct ivar access. An object accessed through a property should
always be treated as +0, i.e. not owned by the caller. However, an object
accessed through an ivar may be at +0 or at +1, depending on whether the
ivar is a strong reference. Outside of ARC, we don't always have that
information.
The previous attempt would clear out the +0 provided by a getter, but only
if that +0 hadn't already participated in other retain counting operations.
(That is, "self.foo" is okay, but "[[self.foo retain] autorelease]" is
problematic.) This turned out to not be good enough when our synthesized
getters get involved.
This commit drops the notion of "overridable" reference counting and instead
just tracks whether a value ever came from a (strong) ivar. If it has, we
allow one more release than we otherwise would. This has the added benefit
of being able to catch /some/ overreleases of instance variables, though
it's not likely to come up in practice.
We do still get some false negatives because we currently throw away
refcount state upon assigning a value into an ivar. We should probably
improve on that in the future, especially once we synthesize setters as
well as getters.
rdar://problem/18075108
llvm-svn: 228174
Summary:
Allow user to provide multiple blacklists by passing several
-fsanitize-blacklist= options. These options now don't override
default blacklist from Clang resource directory, which is always
applied (which fixes PR22431).
-fno-sanitize-blacklist option now disables all blacklists that
were specified earlier in the command line (including the default
one).
This change depends on http://reviews.llvm.org/D7367.
Test Plan: regression test suite
Reviewers: timurrrr
Subscribers: cfe-commits, kcc, pcc
Differential Revision: http://reviews.llvm.org/D7368
llvm-svn: 228156
This lets clang-format format
__try {
} __except(0) {
}
and
__try {
} __finally {
}
correctly. __try and __finally are keywords if `LangOpts.MicrosoftExt` is set,
so this turns this on. This also enables a few other keywords, but it
shouldn't overly perturb regular clang-format operation. __except is a
context-sensitive keyword, so `AdditionalKeywords` needs to be passed around to
a few more places.
Fixes PR22321.
llvm-svn: 228148
Summary:
Named registers with the constraint "=&r" currently lose the early clobber flag
and turn into "=r" when converted to LLVM-IR. This patch correctly passes it on.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7346
llvm-svn: 228143
__declspec(restrict) and __attribute(malloc) are both handled
identically by clang: they are allowed to the noalias LLVM attribute.
Seeing as how noalias models the C99 notion of 'restrict', rename the
internal clang attribute to Restrict from Malloc.
llvm-svn: 228120
When the condition is a vector, OpenCL specifies additional
requirements on the operand types, and also the operations
required to determine the result type of the operator. This is a
combination of OpenCL v1.1 s6.3.i and s6.11.6, and the semantics
remain unchanged in later versions of OpenCL.
llvm-svn: 228118
Some standard header files from MSVC2012 use 'mutable' on references, though it is directly prohibited by the standard.
Fix for http://llvm.org/PR22444
Differential Revision: http://reviews.llvm.org/D7370
llvm-svn: 228113
Previously, when the following piece of code was compiled, clang would
incorrectly warn that the size of "wide_two" does not match register size
specified by the constraint and modifier":
long wide_two = two;
asm ("%w0 %1" : "+r" (one), "+r"(wide_two));
This was caused by a miscalculation of ConstraintIdx in Sema::ActOnGCCAsmStmt.
This commit fixes PR21270 and rdar://problem/18668354.
llvm-svn: 228089
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
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
Clang asserts for this pointer reference in asms of naked functions.
This patch diagnoses if this pointer reference is used.
Differential Revision: http://reviews.llvm.org/D7329
llvm-svn: 228052
These checks detect potential deadlocks caused by inconsistent lock
ordering. The checks are implemented under the -Wthread-safety-beta flag.
This patch also replaces calls to getAttrs() with calls to attrs() throughout
ThreadSafety.cpp, which fixes the earlier issue that cause assert failures.
llvm-svn: 228051
Appends the username to the first component (after the temp dir) of the
module cache path. If the username contains a character that shouldn't
go into a path (for now conservatively allow [a-zA-Z0-9_]), we fallback
to the user id.
llvm-svn: 228013
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.
Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.
rdar://problem/19670595
llvm-svn: 228003
These checks detect potential deadlocks caused by inconsistent lock
ordering. The checks are implemented under the -Wthread-safety-beta flag.
llvm-svn: 227997
Thou shall not jump into SEH blocks. Jumping out of SEH __try and __excepts
is A-ok. Jumping out of __finally blocks is B-ok (msvc doesn't error about it,
but warns that it has undefined behavior).
I've checked that clang's behavior with this patch matches msvc's behavior.
We don't have the warning on jumping out of a __finally yet, see the FIXME
in the test. clang also currently crashes on codegen for a jump out of a
__finally block, see PR22414 comment 7.
I also added a few tests for the interaction of indirect jumps and SEH blocks.
MSVC doesn't support indirect jumps, so there's no way to know if clang behave
the same way as msvc here. clang's behavior with this patch does make sense
to me, but maybe it could be argued that it should be more permissive (see
FIXME in the indirect jump tests -- shout if you have an opinion on this).
llvm-svn: 227982
-save-temps=cwd is equivalent to -save-temps
-save-temps=obj saves temporary file in the same directory as output
This helps to avoid clobbering of temp files in case of parallel
compilation with -save-temps of the files that have the same name
but located in different directories.
Patch by Artem Belevich
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D7304
llvm-svn: 227886
This check does not apply when Borland extensions are enabled, as they
have a checked in test case indicating that mixed usage of SEH and C++
is supported.
llvm-svn: 227876
Summary:
This is especially important for targets that use multiple address spaces,
and commonly place global variables in address spaces other than zero.
Fixes PR22383
Test Plan: New test case added: llvm-used.cu
Reviewers: jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7345
llvm-svn: 227861
It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual function tables.
This commit implements this feature in clang.
llvm-svn: 227796
This used to crash, complaining "ObjectType and scope specifier cannot coexist":
struct A { } b = b.~A::A <int>;
The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a
non-empty ObjectType clears the ObjectType of the scope specifier comes back
non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()),
so do that here too.
Found by SLi's bot.
llvm-svn: 227781
This moves all of the PassManager <-> Target communication to use the
new pass manager's TargetIRAnalysis even with the old pass manager. See
the LLVM commit for some of why things are moving in this direction, but
the short version is that this will enable us to create per-function
TargetTransformInfo objects that have correct subtarget information for
that function.
llvm-svn: 227732
Create a new TargetCodeGenInfo for Windows on ARM to permit annotating the
functions with stack-probe-size (for /Gs and -mstack-probe-support) for
generating the stack probe necessary for Windows targets. This will be used by
the backend when lowering the frame to generate the stack probe appropriately.
llvm-svn: 227641
Even with r227555, this still crashed:
struct S {
int A;
~A::A() {}
};
That's because ParseOptionalCXXScopeSpecifier()'s call to
ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema
thought it's a good idea to fixit-correct "::" to ":". For the diagnostic
improvement done in r217302, we never want :: to be interpreted as :, so fix
this by setting ColonSacred to false temporarily.
Found by SLi's bot.
llvm-svn: 227581
In OpenCL 1.2, using double no longer requires using the pragma cl_khr_fp64,
instead a kernel is allowed to use double, but must first have queried
clGetDeviceInfo's CL_DEVICE_DOUBLE_FP_CONFIG.
Page 197, section 6.1.1 of the OpenCL 1.2 specification has a footnote 23
describing this behaviour.
I've also added test cases such that the pragma must be used if targeting
OpenCL 1.0 or 1.1, but is ignored in 1.2 and 2.0.
Patch by Neil Henning!
Reviewers: Pekka Jääskeläinen
Differential Revision: http://reviews.llvm.org/D7245
llvm-svn: 227565
Fatal errors disable all further diagnostics. Continuing to permit
template instantiation does nothing but make it take longer for clang to
finish with the TU.
Instead, halt all further instantiation.
Fixed in PR22396.
llvm-svn: 227556
Summary:
The PS4 defaults to -fno-rtti, and has to have rtti enabled when enabling
exceptions.
This commit makes clang add the -fno-rtti by default on the PS4, unless
-frtti was passed in.
It also diagnoses misuses for the PS4:
- Exceptions need rtti. Warn and enable rtti if no rtti flag was passed,
error if -fno-rtti was passed.
I also added a more general warning for when -fno-rtti is the default
(currently it's only on the PS4) and the vptr sanitizer is on.
Fixed a few tests, due to different flag order when passing cc1 arguments.
Reviewers: chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7250
llvm-svn: 227518
Work around a bug in GNU ld (and gold) linker versions up to 2.25
that may mis-optimize code generated by this version of clang/LLVM
to access general-dynamic or local-dynamic TLS variables.
Bug is fixed here:
https://sourceware.org/ml/binutils/2015-01/msg00318.html
llvm-svn: 227480
I have so far not succeeded in finding a nicely reduced test case or an
observable difference which could help me create a test failure without
msan.
Committing without test to unblock kcc's further fuzzing progress.
llvm-svn: 227433
On targets which use the MSVCRT, setjmp is a macro which expands to
_setjmp or _setjmpex.
_setjmp and _setjmpex have a secret, hidden argument which is not listed
in the function prototype on X64 and WoA. This hidden argument always
seems to be the frame pointer.
_setjmpex isn't used on X86, _setjmp is magically replaced with a call
to _setjmp3. The second argument is zero for 'normal' setjmp/longjmp
pairs, otherwise it is a count of additional variadic arguments. This
is used when setjmp appears inside of a try or __try.
It is not safe to use a pointer to setjmp because _setjmp, _setjmpex and
_setmp3 are not compatible with setjmp.
llvm-svn: 227426
Summary:
They just existed before to use NaCl's custom ABIInfos; now that those are gone,
the custom TargetCodeGenInfos are no longer needed either.
Test Plan: don't break the existing tests
Reviewers: jvoung
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D7234
llvm-svn: 227406
Those used the old Big Endian support on ARM and don't need flags.
Refactor the logic in a separate common function, which also looks at
-march. Add corresponding logic for the Linux toolchain.
llvm-svn: 227393
Summary:
This was already done for the sanitizers, but it needs to be done for
the profile and builtin libs as well.
Reviewers: srhines, timmurray, eugenis, samsonov
Reviewed By: samsonov
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D7187
llvm-svn: 227392
list-initialization that gets converted to some form other than an
InitListExpr. CXXTemporaryObjectExpr is a special case here, because it
represents a fused CXXFunctionalCastExpr + CXXConstructExpr. That, in
itself, is probably a design error...
llvm-svn: 227377
infinite recursion.
Also guard against said infinite recursion by adding an assert that will
trigger if CorrectDelayedTyposInExpr is called before a previous call to
CorrectDelayedTyposInExpr returns (i.e. if the TreeTransform run by
CorrectDelayedTyposInExpr calls a sequence of methods that
end up calling CorrectDelayedTyposInExpr, as the new test case had done
prior to this commit). Fixes PR22292.
llvm-svn: 227368
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
Reviewers: jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7206
llvm-svn: 227362
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
Daniel Jasper