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
If you request that the file manager not close your file immediately
after reading, it's useful to be able to close it later to prevent a
file descriptor leak.
llvm-svn: 228407
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
This patch adds an extra test case to clang-exception-flags.cpp.
No functional change intended.
Patch by Wolfgang Pieb!
Reviewers: filcab, alexr
Differential Revision: http://reviews.llvm.org/D7298
llvm-svn: 228394
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
Summary:
This test was failing if LLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 due to
its behavior for exceptions.
Force an --unknown triple for the default case.
Reviewers: echristo, chandlerc
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7422
llvm-svn: 228337
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
Benjamin Kramer