| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
consistently, rather than sometimes performing lookup and calling the
LookupResult form. No functionality change intended.
llvm-svn: 209941
|
| |
|
|
|
|
|
|
| |
This simplifies code flow and matches the convention used in surrounding code.
No functional change.
llvm-svn: 209936
|
| |
|
|
| |
llvm-svn: 209935
|
| |
|
|
|
|
| |
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 presumably got inadvertently copied from dllimport-members.cpp.
llvm-svn: 209919
|
| |
|
|
| |
llvm-svn: 209915
|
| |
|
|
| |
llvm-svn: 209913
|
| |
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209904
|
| |
|
|
|
|
|
|
| |
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: 209893
|
| |
|
|
|
|
| |
[basic.scope.pdecl]p10, and our current test for that is more thorough (though our test is named p9.cpp).
llvm-svn: 209892
|
| |
|
|
|
|
| |
test contents are acceptable. No diagnostics expected from this test.
llvm-svn: 209891
|
| |
|
|
|
|
| |
documentation can be properly generated.
llvm-svn: 209890
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
You could see unexpected result (*.tmp.err) with "-target x86_64-win32".
Weverything-and-remarks.cpp:11:9: warning: 'char32_t' type specifier is incompatible with C++98 [-Wc++98-compat]
typedef __char32_t char32_t;
^
Weverything-and-remarks.cpp:12:27: error: typedef redefinition with different types ('unsigned long' vs 'unsigned long long')
typedef long unsigned int size_t;
^
Weverything-and-remarks.cpp:19:62: warning: dynamic exception specifications are deprecated [-Wdeprecated]
static void assign(char_type& __c1, const char_type& __c2) throw() {
^~~~~~~
Weverything-and-remarks.cpp:19:62: note: use 'noexcept' instead
static void assign(char_type& __c1, const char_type& __c2) throw() {
^~~~~~~
noexcept
Weverything-and-remarks.cpp:25:46: warning: unused parameter '__n' [-Wunused-parameter]
size_t __n) {
^
3 warnings and 1 error generated.
llvm-svn: 209878
|
| |
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 209842
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds documentation for -Rpass, -Rpass-missed and -Rpass-analysis.
It also adds release notes for 3.5.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3730
llvm-svn: 209841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 209831
|
| |
|
|
| |
llvm-svn: 209830
|
| |
|
|
| |
llvm-svn: 209828
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
specified with an MSVC build, it defaults to -std=c++11, which overrides the -x cuda option. In turn, this causes all CUDA language option checks to fail.
This fix is possibly temporary while we determine whether -x cuda should be considered along with -std=c++11 when setting language options.
llvm-svn: 209808
|
| |
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before r160106 there was a way to recursively visit all descendants of a cursor
via Cursor_visit, but it was removed. Since then, every user needs to
reimplement the recursive descent into get_children.
Adding a walk_preorder() method to Cursor that conveniently implements recursive
walking in a Pythonic way. This also greatly simplifies get_cursor and
get_cursors in tests/cindex/util.py (walk_preorder is now tested through these
utility functions, since they are used in many tests).
llvm-svn: 209793
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Until now all CUDA-specific attributes were represented with
CXCursor_UnexposedAttr; now they are actually implemented, including the Python
bindings.
llvm-svn: 209767
|
| |
|
|
|
|
|
|
| |
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
|