| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209949
|
| |
|
|
|
|
| |
{extract,insert} vector element instructions.
llvm-svn: 209942
|
| |
|
|
|
|
|
| |
consistently, rather than sometimes performing lookup and calling the
LookupResult form. No functionality change intended.
llvm-svn: 209941
|
| |
|
|
|
|
| |
qualified name of a NamedDecl. Patch by Volodymyr Sapsai!
llvm-svn: 209924
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.
original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209922
|
| |
|
|
|
|
| |
This reverts commit r209910, which is breaking some of the bots.
llvm-svn: 209911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.
So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.
Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.
<rdar://problem/17038180>
llvm-svn: 209910
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.
This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.
Differential Revision: http://reviews.llvm.org/D3877
llvm-svn: 209908
|
| |
|
|
|
|
|
| |
an Objective-C object type other than 'id'.
// rdar://16739120
llvm-svn: 209906
|
| |
|
|
|
|
|
|
| |
There shouldn't be any difference in behaviour here, at least not in
any configurations people care about and possibly not in any reachable
configurations.
llvm-svn: 209899
|
| |
|
|
| |
llvm-svn: 209876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://llvm.org/bugs/show_bug.cgi?id=19876
The following C++1y code results in a crash:
struct X {
int m = 10;
int n = [this](auto) { return m; }(20);
};
When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.
I considered two ways to fix this:
1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.
I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).
Richard Smith accepted the patch:
http://reviews.llvm.org/D3935
Thank you!
llvm-svn: 209874
|
| |
|
|
|
|
| |
deleted default constructor
llvm-svn: 209869
|
| |
|
|
| |
llvm-svn: 209867
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D3963
llvm-svn: 209859
|
| |
|
|
| |
llvm-svn: 209847
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These intrinsics are special because they directly take a memory operand (AVX2
adds the register counterparts). Typically, other non-memop intrinsics take
registers and then it's left to isel to fold memory operands.
In order to LICM intrinsics directly reading memory, we require that no stores
are in the loop (LICM) or that the folded load accesses constant memory
(MachineLICM). When neither is the case we fail to hoist a loop-invariant
broadcast.
We can work around this limitation if we expose the load as a regular load and
then just implement the broadcast using the vector initializer syntax. This
exposes the load to LICM and other optimizations.
At the IR level this is translated into a series of insertelements. The
sequence is already recognized as a broadcast so there is no impact on the
quality of codegen.
_mm256_broadcast_pd and _mm256_broadcast_ps are not updated by this patch
because right now we lack the DAG-combiner smartness to recover the broadcast
instructions. This will be tackled in a follow-on.
There will be completing changes on the LLVM side to remove the LLVM
intrinsics and to auto-upgrade bitcode files.
Fixes <rdar://problem/16494520>
llvm-svn: 209846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
These two flags are in the same family as -Rpass, but are used in
different situations.
-Rpass-missed is used by optimizers to inform the user when they tried
to apply an optimization but couldn't (or wouldn't).
-Rpass-analysis is used by optimizers to report analysis results back
to the user (e.g., why the transformation could not be applied).
Depends on D3682.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3683
llvm-svn: 209839
|
| |
|
|
| |
llvm-svn: 209836
|
| |
|
|
| |
llvm-svn: 209827
|
| |
|
|
| |
llvm-svn: 209826
|
| |
|
|
|
|
|
| |
Redeclarations cannot add a dll attribute and static data members cannot
be defined.
llvm-svn: 209825
|
| |
|
|
|
|
| |
option. This allows -x cuda -std=c++11, for instance.
llvm-svn: 209824
|
| |
|
|
|
|
|
|
|
|
|
| |
With -Weverything, the backend remarks are enabled. This was
causing spurious diagnostics for remarks that we don't yet
handle (cf http://reviews.llvm.org/D3683).
This will stop being a problem once http://reviews.llvm.org/D3683
is committed.
llvm-svn: 209823
|
| |
|
|
| |
llvm-svn: 209816
|
| |
|
|
| |
llvm-svn: 209812
|
| |
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
| |
|
|
|
|
|
| |
member functions), ensure that the redecl chain never transitions from 'inline'
to 'not inline', since that violates an AST invariant.
llvm-svn: 209794
|
| |
|
|
|
|
|
|
|
| |
Clang knows about the sanitizer blacklist and it makes no sense to
add global to the list of llvm.asan.dynamically_initialized_globals if it
will be blacklisted in the instrumentation pass anyway. Instead, we should
do as much blacklisting as possible (if not all) in the frontend.
llvm-svn: 209789
|
| |
|
|
|
|
| |
deduce any packs that are expanded by both expansions.
llvm-svn: 209786
|
| |
|
|
|
|
| |
local contexts. Also includes some minor refactoring.
llvm-svn: 209774
|
| |
|
|
|
|
| |
(fixes PR19431 - http://llvm.org/bugs/show_bug.cgi?id=19431)
llvm-svn: 209769
|
| |
|
|
|
|
|
|
| |
I opened a discussion on cfe-commits. Ideally we've got a few things
that need to happen. CompilerRT should probably have blacklists tests.
Asan should probably not depend on that specific field.
llvm-svn: 209766
|
| |
|
|
|
|
|
|
|
|
| |
Since the continuation block of the if statement is emitted within the
condition scope this had the undesirable effect of creating a line table
entry at the end of the then or else statement, a line that may have never
been executed.
PR19864 / rdar://problem/17052973
llvm-svn: 209764
|
| |
|
|
|
|
|
| |
now deprecated, ObjC containers instead of crashing.
// rdar://16859666
llvm-svn: 209758
|
| |
|
|
|
|
|
| |
in Objective-C container declarations (but not
in their definitions. // rdar://10414277
llvm-svn: 209751
|
| |
|
|
|
|
|
| |
There is no libpthread.so, and pthread interface is implemented in libc.so.
This mirrors gcc behavior.
llvm-svn: 209731
|
| |
|
|
|
|
|
|
|
| |
These note diags have the same message and can be unified further but for now
let's just bring them together.
Incidental change: Display a source range in the final attr diagnostic.
llvm-svn: 209728
|
| |
|
|
| |
llvm-svn: 209727
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before (with just the right line length:
switch (a) {
case some_namespace::some_constant
:
return;
}
After:
switch (a) {
case some_namespace::
some_constant:
return;
}
llvm-svn: 209725
|
| |
|
|
|
|
| |
type in a function type where the C++ type is a reference. Update the tests.
llvm-svn: 209723
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Especially, reduce the amount of indentation if it doesn't increase
readability.
Before:
NSMutableDictionary* dictionary = [NSMutableDictionary
dictionaryWithDictionary:@{
aaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaa,
bbbbbbbbbbbbbbbbbb : bbbbb,
cccccccccccccccc : ccccccccccccccc
}];
After:
NSMutableDictionary* dictionary =
[NSMutableDictionary dictionaryWithDictionary:@{
aaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaa,
bbbbbbbbbbbbbbbbbb : bbbbb,
cccccccccccccccc : ccccccccccccccc
}];
llvm-svn: 209720
|
| |
|
|
|
|
| |
threadprivate vars
llvm-svn: 209716
|
| |
|
|
| |
llvm-svn: 209714
|
| |
|
|
| |
llvm-svn: 209713
|
| |
|
|
|
|
| |
be performed by using Decl::isInStdNamespace or DeclContext::isStdNamespace
llvm-svn: 209708
|
| |
|
|
|
|
|
|
|
|
|
|
| |
MSVC doesn't export these functions, so trying to import them doesnt' work.
Also, don't let any dll attributes on the CXXDestructorDecl influence the
thunk's linkage -- they should always be linkonce_odr.
This takes care of the FIXME's for this in Nico's tests.
Differential Revision: http://reviews.llvm.org/D3930
llvm-svn: 209706
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates.
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3924
llvm-svn: 209686
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds LambdaExpr::captures(), LambdaExpr::explicit_captures()
and LambdaExpr::implicit_captures() as simple wrappers over the underlying
*_begin()/*_end() functions.
Reviewers: aaron.ballman
Differential Revision: http://reviews.llvm.org/D3926
llvm-svn: 209679
|
| |
|
|
|
|
|
| |
same framework after complaining about duplicate class definition.
// rdar://17024681
llvm-svn: 209672
|