| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
Before:
DEPRECATED("Use NewClass::NewFunction instead.") int OldFunction(
const string ¶meter) {}
Could not be formatted at all, as clang-format would both require and
disallow the break before "int".
llvm-svn: 245846
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
more consistent.
Before:
SomeType MemberFunction(const Deleted &)&&;
SomeType MemberFunction(const Deleted &) && { ... }
After:
SomeType MemberFunction(const Deleted &)&&;
SomeType MemberFunction(const Deleted &)&& { ... }
llvm-svn: 245843
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A \
{ a, a } \
,
After:
#define A {a, a},
llvm-svn: 245837
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The ACLE (ARM C Language Extensions) 2.0 defines that the predefined macro
__ARM_FP16_ARGS should be defined if __fp16 can be used as an argument and
result.
The support for __fp16 to be used as an argument and result is already
implemented for AArch64 so this change is just adding the missing macro.
Differential Revision: http://reviews.llvm.org/D12240
llvm-svn: 245833
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D12152
llvm-svn: 245823
|
| |
|
|
|
|
| |
whether the owning module of a hidden declaration is visible -- it can't be.
llvm-svn: 245822
|
| |
|
|
|
|
|
| |
unnecessary in C++ modules (where we don't need the identifiers for their
Decls) and expensive.
llvm-svn: 245821
|
| |
|
|
|
|
| |
Patch by Kai Zhao!
llvm-svn: 245817
|
| |
|
|
| |
llvm-svn: 245815
|
| |
|
|
|
|
|
|
| |
I'm not sure why TypoExpr had its classof left out - but I expect every AST node should fulfill the 'contract of classof' (http://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html).
There should be no functionality change. I just happened to notice it was missing, while messing around with something else.
llvm-svn: 245812
|
| |
|
|
| |
llvm-svn: 245811
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a function declaration is found inside a template function as in:
template<class T> void f() {
void g(int x = T::v) except(T::w);
}
it must be instantiated along with the enclosing template function,
including default arguments and exception specification.
Together with the patch committed in r240974 this implements DR1484.
Differential Revision: http://reviews.llvm.org/D11194
llvm-svn: 245810
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The signatures of the methods in LLVM for creating EH pads/rets are changing
to require token arguments on rets and assume token return type on pads.
Update creation code accordingly.
Reviewers: majnemer, rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12109
llvm-svn: 245798
|
| |
|
|
|
|
|
| |
pick the most recent declaration, and we can often tell which declaration is
more recent without walking the redeclaration chain. Do so when possible.
llvm-svn: 245794
|
| |
|
|
|
|
|
|
| |
Instead of eagerly deserializing a list of DeclIDs when we load a module file
and doing a binary search to find the redeclarations of a decl, store a list of
redeclarations of each chain before the first declaration and load it directly.
llvm-svn: 245789
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
According to CUDA documentation, global variables declared with __device__,
__constant__ can be initialized from host code, so mark them as
externally initialized. Because __shared__ variables cannot have an
initialization as part of their declaration and since the value maybe kept
across different kernel invocation, the value of __shared__ is effectively
undefined instead of zero initialized.
Wrongly using zero initializer may cause illegitimate optimization, e.g.
removing unused __constant__ variable because it's not updated in the device
code and the value is initialized with zero.
Test Plan: test/CodeGenCUDA/address-spaces.cu
Patch by Xuetian Weng
Reviewers: jholewinski, eliben, tra, jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12241
llvm-svn: 245786
|
| |
|
|
| |
llvm-svn: 245780
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
all modules and reduce the number of declarations we load when loading a
redeclaration chain.
The new approach is:
* when loading the first declaration of an entity within a module file, we
first load all declarations of the entity that were imported into that
module file, and then load all the other declarations of that entity from
that module file and build a suitable decl chain from them
* when loading any other declaration of an entity, we first load the first
declaration from the same module file
As before, we complete redecl chains through name lookup where necessary.
To make this work, I also had to change the way that template specializations
are stored -- it no longer suffices to track only canonical specializations; we
now emit all "first local" declarations when emitting a list of specializations
for a template.
On one testcase with several thousand imported module files, this reduces the
total runtime by 72%.
llvm-svn: 245779
|
| |
|
|
|
|
|
|
| |
We can use the 'H' typespec modifier to use 128-bit vectors directly
in the only two users of this special-case: the vcvt f16 intrinsics.
This also lets us use more meaningful prototype modifiers.
llvm-svn: 245778
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a contextually-typed expression that semantic analysis will
probably need to invasively rewrite, don't include the
RHS OVE as a separate semantic expression, and check the
operation with the original RHS expression.
There are two contextually-typed expressions that can survive
to here: overloaded function references, which are at least
safe to double-emit, and C++11 initializer list expressions,
which are not at all safe to double-emit and which often
don't update the original syntactic InitListExpr with
implicit conversions to member types, etc.
This means that the original RHS may appear, undecorated by
an OVE, in the semantic expressions. Fortunately, it will
only ever be used in a single place there, and I don't
believe there are clients that rely on being able to pick
out the original RHS from the semantic expressions.
But this could be problematic if there are clients that do
visit the entire tree and rely on not seeing the same
expression multiple times, once in the syntactic and once
in the semantic expressions. This is a very fiddly part
of the compiler.
rdar://21801088
llvm-svn: 245771
|
| |
|
|
|
|
|
|
|
|
|
| |
We had "vcvt_f16" and "VCVT_HIGH_F16": for other FP types, this naming
is used for intrinsics with integer overloads. The FP->FP conversions,
on the other hand, use the full "vcvt_f32_f64" name instead.
Use the same naming convention for the f16<->f32 conversions.
While there, reorder the definitions a little bit.
llvm-svn: 245763
|
| |
|
|
| |
llvm-svn: 245761
|
| |
|
|
|
|
| |
Patch by modocache (Brian Gesiak).
llvm-svn: 245731
|
| |
|
|
|
|
|
|
| |
Reverting because of 245721
This reverts commit 552658e2b60543c928030b09cc9b5dfcb40c3f28.
llvm-svn: 245727
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generating call assume(icmp %vtable, %global_vtable) after constructor
call for devirtualization purposes.
For more info go to:
http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
Edit:
Fixed version because of PR24479.
http://reviews.llvm.org/D11859
llvm-svn: 245721
|
| |
|
|
|
|
|
|
|
| |
This is important in the case that the LLVM-inferred llvm-struct
alignment is not the same as the clang-known C-struct alignment.
Differential Revision: http://reviews.llvm.org/D12243
llvm-svn: 245719
|
| |
|
|
| |
llvm-svn: 245706
|
| |
|
|
| |
llvm-svn: 245700
|
| |
|
|
| |
llvm-svn: 245698
|
| |
|
|
|
|
|
|
|
| |
Add emission of metadata for simd loops in presence of 'simdlen' clause.
If 'simdlen' clause is provided without 'safelen' clause, the vectorizer width for the loop is set to value of 'simdlen' clause + all read/write ops in loop are marked with '!llvm.mem.parallel_loop_access' metadata.
If 'simdlen' clause is provided along with 'safelen' clause, the vectorizer width for the loop is set to value of 'simdlen' clause + all read/write ops in loop are not marked with '!llvm.mem.parallel_loop_access' metadata.
If 'safelen' clause is provided without 'simdlen' clause, the vectorizer width for the loop is set to value of 'safelen' clause + all read/write ops in loop are not marked with '!llvm.mem.parallel_loop_access' metadata.
llvm-svn: 245697
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit of a step back of what we did in r222531, as there are
some corner cases in C++, where this kind of formatting is really bad.
Example:
Before:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant = [&]() {
return true;
}, aaaaa aaaaaaaaa);
After:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant =
[&]() { return true; },
aaaaa aaaaaaaaa);
The block formatting logic in JavaScript will probably go some other changes,
too, and we'll potentially be able to make the rules more consistent again. For
now, this seems to be the best approach for C++.
llvm-svn: 245694
|
| |
|
|
| |
llvm-svn: 245693
|
| |
|
|
|
|
| |
Add parsing/sema analysis for 'simdlen' clause in simd directives. Also add check that if both 'safelen' and 'simdlen' clauses are specified, the value of 'simdlen' parameter is less than the value of 'safelen' parameter.
llvm-svn: 245692
|
| |
|
|
| |
llvm-svn: 245685
|
| |
|
|
| |
llvm-svn: 245684
|
| |
|
|
| |
llvm-svn: 245679
|
| |
|
|
|
|
|
|
|
|
|
|
| |
While working around a bug in certain standard library implementations,
we would try to diagnose the issue so that library implementors would
fix their code. However, we assumed an entity being initialized was
a non-static data member subobject when other circumstances are
possible.
This fixes PR24526.
llvm-svn: 245675
|
| |
|
|
|
|
| |
According to standard the 'uval' modifier declares the address of the original list item to have an invariant value for all iterations of the associated loop(s). Patch improves codegen for this qualifier by removing usage of the original reference variable and replacing by referenced l-value.
llvm-svn: 245674
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some reason, clang had been treating a command like:
clang -static -fPIC foo.c
as if it should be compiled without the PIC relocation model.
This was incorrect: -static should be affecting only the linking
model, and -fPIC only the compilation.
This new behavior also matches GCC.
This is a follow-up from a review comment on r245447.
Differential Revision: http://reviews.llvm.org/D12208
llvm-svn: 245667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that -Winfinite-recursion no longer uses recursive calls to before path
analysis, several bits of the code can be improved. The main changes:
1) Early return when finding a path to the exit block without a recursive call
2) Moving the states vector into checkForRecursiveFunctionCall instead of
passing it in by reference
3) Change checkForRecursiveFunctionCall to return a bool when the warning
should be emitted.
4) Use the State vector instead of storing it in the Stack vector.
llvm-svn: 245666
|
| |
|
|
|
|
|
| |
non-visible definition, skip the new definition to avoid ending up with a
function with multiple definitions.
llvm-svn: 245664
|
| |
|
|
|
|
|
|
| |
errors in Objective-C.
Differential Revision: http://reviews.llvm.org/D11427
llvm-svn: 245646
|
| |
|
|
| |
llvm-svn: 245637
|
| |
|
|
|
|
|
|
| |
--use-analyzer="path to clang++.exe").
Don't derive the path_to_clang++ from the path_to_clang if the path_to_clang is really the path_to_clang++.
llvm-svn: 245621
|
| |
|
|
|
|
| |
it as they are already set correctly by X86_64TargetInfo and X86TargetInfo.
llvm-svn: 245620
|
| |
|
|
|
|
|
|
| |
That change is causing strange test failures on Fedora 22 (PR24503),
and it does not have any effect with Gold linker anyway (PR15823,
https://sourceware.org/bugzilla/show_bug.cgi?id=18859).
llvm-svn: 245619
|
| |
|
|
| |
llvm-svn: 245618
|
| |
|
|
|
|
| |
delayed template parse of its body.
llvm-svn: 245616
|
| |
|
|
| |
llvm-svn: 245609
|
| |
|
|
| |
llvm-svn: 245607
|