| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
If member expression is used in the task region and the base expression
is a DeclRefExp and the variable used in this ref expression is private,
it should be marked as implicitly firstprivate inside this region. Patch
fixes this issue.
llvm-svn: 288039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
clang-tidy checks frequently use source ranges of functions.
The source range of constructors and destructors in template instantiations
is currently a single token.
The factory method for constructors and destructors does not allow the
end source location to be specified.
Set end location manually after creating instantiation.
Reviewers: aaron.ballman, rsmith, arphaman
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D26849
llvm-svn: 288025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since r274049, for an inheriting constructor declaration, the name of the using
declaration (and using shadow declaration comes from the using declaration) is
the name of a derived class, not the base class (line 8225-8232 of
lib/Sema/SemaDeclCXX.cpp in https://reviews.llvm.org/rL274049). Because of
this, name-based lookup performed inside Sema::LookupConstructors returns not
only CXXConstructorDecls but also Using(Shadow)Decls, which results assertion
failure reported in PR29087.
Patch by Taewook Oh, thanks!
Differential Revision: https://reviews.llvm.org/D23765
llvm-svn: 287999
|
|
|
|
|
|
|
|
|
| |
Documentation for some of the avxintrin.h's intrinsics errorneously said that
non VEX-prefixed instructions could be generated. This was fixed.
I tried several different solutions to achieve pretty printing of unordered lists (nested and non-nested) in param sections in doxygen.
llvm-svn: 287990
|
|
|
|
| |
llvm-svn: 287947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the `FromDecl` is a class forward declaration, the reference is
still considered as referring to the original definition given the nature
of forward-declarations, so we can't do a raw name replacement in this case.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D27132
llvm-svn: 287929
|
|
|
|
| |
llvm-svn: 287926
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For example, this case was missed when looking for different but canonical
namespaces. UseContext in this case should be considered as in the canonical
namespace.
```
namespace a { namespace b { <FromContext> } }
namespace a { namespace b { namespace c { <UseContext> } } }
```
Added some commenting.
Reviewers: bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D27125
llvm-svn: 287924
|
|
|
|
|
|
|
| |
No functionality change. Found by clang-tidy's
performance-unnecessary-value-param.
llvm-svn: 287894
|
|
|
|
|
|
| |
No functional change.
llvm-svn: 287892
|
|
|
|
|
|
|
| |
No functionality change intended. Fix by clang-tidy's
performance-unnecessary-value-param check.
llvm-svn: 287890
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(commit again after fixing the buildbot failures)
This adds various overloads of the following builtins to altivec.h:
vec_neg
vec_nabs
vec_adde
vec_addec
vec_sube
vec_subec
vec_subc
Note that for vec_sub builtins on 32 bit integers, the semantics is similar to
what ISA describes for instructions like vsubecuq that work on quadwords: the
first operand is added to the one's complement of the second operand. (As
opposed to two's complement which I expected).
llvm-svn: 287872
|
|
|
|
| |
llvm-svn: 287859
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27006
llvm-svn: 287852
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D26827
llvm-svn: 287851
|
|
|
|
| |
llvm-svn: 287847
|
|
|
|
|
|
| |
A test that passed locally is failing on one of the build bots.
llvm-svn: 287796
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(commit again after fixing the buildbot failures)
This adds various overloads of the following builtins to altivec.h:
vec_neg
vec_nabs
vec_adde
vec_addec
vec_sube
vec_subec
vec_subc
Note that for vec_sub builtins on 32 bit integers, the semantics is similar to
what ISA describes for instructions like vsubecuq that work on quadwords: the
first operand is added to the one's complement of the second operand. (As
opposed to two's complement which I expected).
llvm-svn: 287795
|
|
|
|
|
|
| |
Follow up to r287774
llvm-svn: 287793
|
|
|
|
|
|
|
|
|
|
|
| |
This commit teaches clang that is has to emit a warning when NULL is passed
as the 'expected' pointer parameter into an atomic compare exchange call.
rdar://18926650
Differential Revision: https://reviews.llvm.org/D26978
llvm-svn: 287776
|
|
|
|
|
|
| |
Due to buildbot failure, I revert. Will recommit after investigation.
llvm-svn: 287775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We don't need a side table in ASTContext to hold CXXDefaultArgExprs. The
important part of building the CXXDefaultArgExprs was to ODR use the
default argument expressions, not to make AST nodes. Refactor the code
to only check the default argument, and remove the side table in
ASTContext which wasn't being serialized.
Fixes PR31121
Reviewers: thakis, rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27007
llvm-svn: 287774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds various overloads of the following builtins to altivec.h:
vec_neg
vec_nabs
vec_adde
vec_addec
vec_sube
vec_subec
vec_subc
Note that for vec_sub builtins on 32 bit integers, the semantics is similar to
what ISA describes for instructions like vsubecuq that work on quadwords: the
first operand is added to the one's complement of the second operand. (As
opposed to two's complement which I expected).
llvm-svn: 287772
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes an incorrectly formatted Objective-C block parameter
placeholder in a code completion result. The incorrect parameter had a
redundant leading parenthesis.
rdar://25224416
llvm-svn: 287771
|
|
|
|
|
|
|
|
| |
Patch by: Kareem Khazem
Differential Revision: https://reviews.llvm.org/D26328
llvm-svn: 287763
|
|
|
|
|
|
| |
Missed in rL287733
llvm-svn: 287755
|
|
|
|
| |
llvm-svn: 287754
|
|
|
|
| |
llvm-svn: 287733
|
|
|
|
|
|
|
| |
complete a little more general; it is produced in other cases than the one that
it previously talked about.
llvm-svn: 287713
|
|
|
|
| |
llvm-svn: 287691
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21741
llvm-svn: 287689
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, TargetLibraryInfoWrapperPass is inserted by PMBuilder.
However, some passes are inserted manually before the PMBuilder
ones - if any of them happens to use TargetLibraryInfoWrapperPass,
it'll get a default-constructed one, with an unknown target triple.
This happens to InstrProfiling in D21736, breaking it.
Differential Revision: http://reviews.llvm.org/D21737
llvm-svn: 287688
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://reviews.llvm.org/D25932 made it so that clang always checks if
libLTO.dylib is present on disk, even if -flto is not being used. The
motivation for that change was that if a dependency happens to contain bitcode,
ld64 will try to load libLTO without -flto explicitly being enabled. However,
the change had the undesirable side effect of warning if libLTO.dylib doesn't
exist even if it isn't needed.
Change things so that -lto_library is always passes, independent of if it
exists or not. ld64 only looks at this flag if it uses LTO. If the dylib
exists, all is well. If it doesn't, and LTO is not being used, all is well too.
If ld64 does end up using LTO and the dylib does not exist, ld64 will print
something like
ld: could not process llvm bitcode object file, because foo/libLTO.dylib could not be loaded file 'test.o' for architecture x86_64
https://reviews.llvm.org/D26984
llvm-svn: 287685
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The new error information contains the type of error (e.g. overlap or bad file path)
and the replacement(s) that is causing the error. This enables us to resolve some errors.
For example, for insertion at the same location conflict, we need to know the
existing replacement which conflicts with the new replacement in order to calculate
the new position to be insert before/after the existing replacement (for merging).
Reviewers: klimek, bkramer
Subscribers: djasper, cfe-commits
Differential Revision: https://reviews.llvm.org/D26853
llvm-svn: 287639
|
|
|
|
| |
llvm-svn: 287633
|
|
|
|
|
|
|
| |
The new option -pass-remarks-output broke LLVM_LINK_LLVM_DYLIB because
of the duplicate option name with opt.
llvm-svn: 287628
|
|
|
|
|
|
|
|
|
|
|
| |
Because in case of unions we currently default-bind compound values in the
store, this quick fix avoids the crash for this case.
Patch by Ilya Palachev and independently by Alexander Shaposhnikov!
Differential Revision: https://reviews.llvm.org/D26442
llvm-svn: 287618
|
|
|
|
| |
llvm-svn: 287602
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
under the Microsoft C++ ABI.
This is needed because whether the constructor is deleted can control whether
we pass structs by value directly.
To fix this properly we probably want a more direct way for CodeGen to ask
whether the constructor was deleted.
Fixes PR31049.
Differential Revision: https://reviews.llvm.org/D26822
llvm-svn: 287600
|
|
|
|
| |
llvm-svn: 287599
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a method that was declared in an invalid interface
This commit fixes an infinite loop that occurs when clang tries to iterate over
redeclaration of a method that was declared in an invalid @interface. The
existing validity checks don't catch this as that @interface is a duplicate of
a previously declared valid @interface declaration, so we have to verify that
the found redeclaration is in a valid declaration context.
rdar://29220965
Differential Revision: https://reviews.llvm.org/D26664
llvm-svn: 287530
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a new predefined macro named __OBJC_BOOL_IS_BOOL that describes
the Objective-C boolean type: its value is zero if the Objective-C boolean uses
the signed character type, otherwise its value is one as the Objective-C boolean
uses the builtin boolean type.
rdar://21170440
Differential Revision: https://reviews.llvm.org/D26234
llvm-svn: 287529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds XRay support in Clang for AArch64 target.
This patch is one of a series:
LLVM: https://reviews.llvm.org/D26412
compiler-rt: https://reviews.llvm.org/D26413
Author: rSerge
Reviewers: rengolin, dberris
Subscribers: aemerson, cfe-commits, iid_iunknown
Differential Revision: https://reviews.llvm.org/D26415
llvm-svn: 287518
|
|
|
|
|
|
|
|
|
|
| |
The doxygen comments are automatically generated based on Sony's intrinsics docu
ment.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream. This patch was internally reviewed by Charles Li.
llvm-svn: 287483
|
|
|
|
|
|
| |
I broke this in r287406 and r287407.
llvm-svn: 287463
|
|
|
|
| |
llvm-svn: 287458
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes it explicit that ownership is taken. Also replace all `new`
with make_unique<> at call sites.
Reviewers: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D26884
llvm-svn: 287449
|
|
|
|
|
|
|
| |
I've adopted this in most of the places it makes sense, but v-tables
and CGObjCMac will need a second pass.
llvm-svn: 287437
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added doxygen comments to avxintrin.h's intrinsics. As of now, all the intrinsics in this file that were documented by Sony's intrinsics guide should have corresponding doxygen comments.
Note: The doxygen comments are automatically generated based on Sony's intrinsic
s document.
I got an OK from Eric Christopher to commit doxygen comments without prior code
review upstream.
Reviewed by Wolfgang Pieb.
llvm-svn: 287436
|
|
|
|
|
|
|
|
| |
both copy operations.
Differential Revision: https://reviews.llvm.org/D26868
llvm-svn: 287411
|