| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Reviewed as part of http://reviews.llvm.org/D20444
llvm-svn: 272720
|
| |
|
|
|
|
|
| |
The reason is that this (a) seems to work just fine and (b) useful when building stuff with
sanitizer+coverage, but need to exclude the sanitizer for a particular source file.
llvm-svn: 272717
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20339
llvm-svn: 272710
|
| |
|
|
| |
llvm-svn: 272702
|
| |
|
|
| |
llvm-svn: 272701
|
| |
|
|
| |
llvm-svn: 272699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After r272599, -DLLVM_BUILD_INSTRUMENTED passes a default argument to
-fprofile-instr-generate. This confuses the perf-helper script because
the runtime emits a note stating that the default is overridden by the
LLVM_PROFILE_FILE environment variable.
Change the perf-helper script s.t it does not treat these notes as
failures.
This isn't a strictly NFC change, but I don't see a simple way to add a
test for it.
llvm-svn: 272695
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: do not add existing includes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21323
llvm-svn: 272669
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before, this could be formatted at all (with BracketAlignmentStyle
AlwaysBreak):
foo = <Bar[]>[
1, /* */
2
];
llvm-svn: 272668
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D21322
llvm-svn: 272667
|
| |
|
|
|
|
|
|
|
|
|
| |
The two patches together enable clang to support targets like
"x86_64-pc-linux-musl" and build binaries against musl-libc instead of
glibc. This make it easy for clang to work on some musl-based systems
like Alpine Linux and certain flavors of Gentoo.
Patch by Lei Zhang.
llvm-svn: 272662
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D20626
llvm-svn: 272658
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is similar to other loop pragmas like 'vectorize'. Currently it
only has state values: distribute(enable) and distribute(disable). When
one of these is specified the corresponding loop metadata is generated:
!{!"llvm.loop.distribute.enable", i1 true/false}
As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally. Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.
There are some slight differences compared to the existing loop pragmas.
1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.
2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'. So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas. We just need to check for duplicates of
the same pragma.
Reviewers: rsmith, dexonsmith, aaron.ballman
Subscribers: bob.wilson, cfe-commits, hfinkel
Differential Revision: http://reviews.llvm.org/D19403
llvm-svn: 272656
|
| |
|
|
| |
llvm-svn: 272654
|
| |
|
|
|
|
|
|
| |
This new diagnostic is causing some false positives that have to be addressed.
This reverts commit 272552
llvm-svn: 272653
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
invalid cases.
Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
error: unknown target ABI 'n64'
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21023
llvm-svn: 272645
|
| |
|
|
|
|
|
|
|
|
|
|
| |
See https://llvm.org/bugs/show_bug.cgi?id=28100.
In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization. Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.
All regression tests pass.
Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.
llvm-svn: 272631
|
| |
|
|
|
|
|
|
|
| |
Support certain MS pragmas right after the closing curly brace of a
class. Clang did not expect __pragma in this position.
This fixes PR28094.
llvm-svn: 272628
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If definition of default function argument uses itself, clang crashed,
because corresponding function parameter is not associated with the default
argument yet. With this fix clang emits appropriate error message.
This change fixes PR28105.
Differential Revision: http://reviews.llvm.org/D21301
llvm-svn: 272623
|
| |
|
|
| |
llvm-svn: 272610
|
| |
|
|
|
|
|
|
|
|
|
| |
pointer-to-pointer representing the parameter. An aggregate rvalue representing
a pointer does not make sense.
We got away with this weirdness because CGCall happens to blindly load an
RValue in aggregate form in this case, without checking whether an RValue for
the type should be in scalar or aggregate form.
llvm-svn: 272609
|
| |
|
|
|
|
| |
constructor.
llvm-svn: 272605
|
| |
|
|
| |
llvm-svn: 272604
|
| |
|
|
|
|
|
|
| |
clang-x64-ninja-win7 buildbot failure.
Patch by Eric Niebler
llvm-svn: 272592
|
| |
|
|
|
|
|
|
|
| |
ActOnBinOp corrects delayed typos when in C mode; don't correct them in that
case. Fixes PR26700.
Differential Revision: http://reviews.llvm.org/D20490
llvm-svn: 272587
|
| |
|
|
|
|
|
|
|
|
|
| |
non-portable #include and #import paths.
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure.
llvm-svn: 272584
|
| |
|
|
|
|
| |
It's useful e.g. for distributed build systems.
llvm-svn: 272583
|
| |
|
|
| |
llvm-svn: 272575
|
| |
|
|
| |
llvm-svn: 272573
|
| |
|
|
| |
llvm-svn: 272572
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading.
It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.
This patch does not add tests - its goal is to keep the existing functionality.
This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.
Reviewers: ABataev, jlebar, echristo, hfinkel, tra
Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin
Differential Revision: http://reviews.llvm.org/D18170
llvm-svn: 272571
|
| |
|
|
| |
llvm-svn: 272569
|
| |
|
|
|
|
| |
This is the same tactic used in linux-header-search.cpp.
llvm-svn: 272568
|
| |
|
|
|
|
|
|
|
| |
There is no need to use a target-specific intrinsic to implement
_bit_scan_forward or _bit_scan_reverse, reimplementing them using
generic intrinsics makes it more likely that the middle end will
understand what's going on.
llvm-svn: 272564
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
non-portable #include and #import paths.
Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842
Re-commit after addressing issues with of generating too many warnings for Windows and asan test failures.
Patch by Eric Niebler
llvm-svn: 272562
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: There's no convention of avoiding the nested indentation.
Reviewers: djasper
Subscribers: klimek, alexeagle, cfe-commits
Differential Revision: http://reviews.llvm.org/D21275
llvm-svn: 272559
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When turned on, clang-format wraps JavaScript imports (and importing exports),
instead of forcing the entire import statement onto one line.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21273
llvm-svn: 272558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member
Differential Revision: http://reviews.llvm.org/D20561
llvm-svn: 272552
|
| |
|
|
|
| |
CR: Michael Zuckerman
llvm-svn: 272549
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Seems this isn't generally desirable.
Before:
int const * a;
After:
int const* a;
llvm-svn: 272548
|
| |
|
|
| |
llvm-svn: 272541
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
__builtin_nontemporal_store in headers
We can now use __builtin_nontemporal_store instead of target specific builtins for naturally aligned nontemporal stores which avoids the need for handling in CGBuiltin.cpp
The scalar integer nontemporal (unaligned) store builtins will have to wait as __builtin_nontemporal_store currently assumes natural alignment and doesn't accept the 'packed struct' trick that we use for normal unaligned load/stores.
The nontemporal loads require further backend support before we can safely convert them to __builtin_nontemporal_load
Differential Revision: http://reviews.llvm.org/D21272
llvm-svn: 272540
|
| |
|
|
|
|
|
|
|
|
| |
Before:
returnsFunction (¶m1, ¶m2)(param);
After:
returnsFunction(¶m1, ¶m2)(param);
llvm-svn: 272538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before (when aligning & to the right):
SomeType MemberFunction(const Deleted &) const&;
After:
SomeType MemberFunction(const Deleted &) const &;
This also applies to variable declarations, e.g.:
int const * a;
However, this form is very uncommon (most people would write
"const int* a" instead) and contracting to "const*" might actually send
the wrong signal of what the const binds to.
llvm-svn: 272537
|
| |
|
|
|
|
|
|
|
|
| |
Before:
auto s = sizeof...(Ts)-1;
After:
auto s = sizeof...(Ts) - 1;
llvm-svn: 272536
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
[]() //
-> int {
return 1; //
};
After:
[]() //
-> int {
return 1; //
};
llvm-svn: 272535
|
| |
|
|
| |
llvm-svn: 272534
|
| |
|
|
|
|
| |
avx512bw, just avx512vl.
llvm-svn: 272532
|
| |
|
|
|
|
|
|
|
|
| |
Create a special visualizer for OpaquePtr<QualType> because the
standard visualizer doesn't work with OpaquePtr<QualType>
due to QualType being heavily dependent on traits to be pointer-like.
Also, created an identical visualizer for UnionOpaquePtr
llvm-svn: 272531
|
| |
|
|
|
|
|
|
|
|
| |
bots happy.
This is a speculative attempt to fix the compiler error: "list initialization inside
member initializer list or non-static data member initializer is not implemented" with
r272529.
llvm-svn: 272530
|