| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42685
llvm-svn: 323860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the CUDA toolkit is not installed to its default locations
in /usr/local/cuda, the user is forced to specify --cuda-path.
This is tedious and the driver can be smarter if well-known tools
(like ptxas) can already be found in the PATH environment variable.
Add option --cuda-path-ignore-env if the user wants to ignore
set environment variables. Also use it in the tests to make sure
the driver always finds the same CUDA installation, regardless
of the user's environment.
Differential Revision: https://reviews.llvm.org/D42642
llvm-svn: 323848
|
|
|
|
|
|
|
|
|
|
|
|
| |
including non-function-like ones
No reason to treat function-like macros differently here.
Tracked in rdar://29907377
Differential Revision: https://reviews.llvm.org/D42444
llvm-svn: 323827
|
|
|
|
|
|
|
|
| |
This reverts commit r294872.
Although this patch is correct, it caused the objc_autoreleaseRValue/objc_retainAutoreleasedReturnValue
llvm-svn: 323814
|
|
|
|
|
|
|
|
|
| |
object."
This reverts commit r323712. It's causing some test failures on certain machines.
Not sure why, will investigate.
llvm-svn: 323717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang can use CUDA-9.1 now, though new APIs (are not implemented yet.
The major change is that headers in CUDA-9.1 went through substantial
changes that started in CUDA-9.0 which required substantial changes
in the cuda compatibility headers provided by clang.
There are two major issues:
* CUDA SDK no longer provides declarations for libdevice functions.
* A lot of device-side functions have become nvcc's builtins and
CUDA headers no longer contain their implementations.
This patch changes the way CUDA headers are handled if we compile
with CUDA 9.x. Both 9.0 and 9.1 are affected.
* Clang provides its own declarations of libdevice functions.
* For CUDA-9.x clang now provides implementation of device-side
'standard library' functions using libdevice.
This patch should not affect compilation with CUDA-8. There may be
some observable differences for CUDA-9.0, though they are not expected
to affect functionality.
Tested: CUDA test-suite tests for all supported combinations of:
CUDA: 7.0,7.5,8.0,9.0,9.1
GPU: sm_20, sm_35, sm_60, sm_70
Differential Revision: https://reviews.llvm.org/D42513
llvm-svn: 323713
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fix NRVO for Gro variable.
Previously, we only marked the GRO declaration as an NRVO variable
when its QualType and the function return's QualType matched exactly
(using operator==). However, this was incorrect for two reasons:
1. We were marking non-class types, such as ints, as being NRVO variables.
2. We failed to handle cases where the canonical types were the same, but the actual `QualType` objects were different. For example, if one was represented by a typedef. (Example: https://godbolt.org/g/3UFgsL)
This patch fixes these bugs by marking the Gro variable as supporting NRVO only
when `BuildReturnStmt` marks the Gro variable as a coroutine candidate.
Reviewers: rsmith, GorNishanov, nicholas
Reviewed By: GorNishanov
Subscribers: majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42343
llvm-svn: 323712
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42562
llvm-svn: 323696
|
|
|
|
| |
llvm-svn: 323679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This disables some of the most commonly used text proto delimiters and functions
for google style until we resolve several style options for that style.
In particular, wheter there should be a space surrounding braces ``msg { sub { key : value } }``
and the extent of packing of submessages on a same line.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42651
llvm-svn: 323678
|
|
|
|
|
|
|
|
|
|
|
|
| |
shortening in HeaderSearch.
Reviewers: bkramer
Subscribers: mgorny, hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D42577
llvm-svn: 323647
|
|
|
|
|
|
| |
"to to" -> "to"
llvm-svn: 323627
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change is step three in the series of changes to remove alignment argument from
memcpy/memmove/memset in favour of alignment attributes. Steps:
Step 1) Remove alignment parameter and create alignment parameter attributes for
memcpy/memmove/memset. ( rL322965, rC322964, rL322963 )
Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing
source and dest alignments. ( rL323597 )
Step 3) Update Clang to use the new IRBuilder API.
Step 4) Update Polly to use the new IRBuilder API.
Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API,
and those that use use MemIntrinsicInst::[get|set]Alignment() to use getDestAlignment()
and getSourceAlignment() instead.
Step 6) Remove the single-alignment IRBuilder API for memcpy/memmove, and the
MemIntrinsicInst::[get|set]Alignment() methods.
Reference
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
Reviewers: rjmccall
Subscribers: jyknight, nemanjai, nhaehnle, javed.absar, sbc100, aheejin, kbarton, fedor.sergeev, cfe-commits
Differential Revision: https://reviews.llvm.org/D41677
llvm-svn: 323617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* CXXOperatorCallExpr
* SizeOfPackExpr
* DependentTemplateSpecializationType
* DependentSizedArray
* CXXTypeidExpr
* Fix importing CXXTemporaryObjectExpr
Some of the changes are based on
https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp
Differential Revision: https://reviews.llvm.org/D42335
llvm-svn: 323589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructor.
Previously, clang would emit an over-aligned (16-byte) store to
initialize B::x in B's base constructor when compiling the following
code:
struct A {
__attribute__((aligned(16))) double data1;
};
struct B : public virtual A {
B() : x(123) {}
double a;
int x;
};
struct C : public virtual B {};
void test() { B b; C c; }
This was happening because the code in IRGen that does member
initialization was using the alignment of a complete object instead of
the non-virtual alignment.
This commit fixes the bug.
rdar://problem/36382481
Differential Revision: https://reviews.llvm.org/D42521
llvm-svn: 323578
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Both MS and PS4 targets are capable of recognizing the
existence of: #pragma region, #pragma endregion.
Since this pragma is only a hint for certain editors, and has no logic,
it seems helpful to permit this pragma in all cases, not just MS compatibility mode.
Reviewers: rnk, rsmith, majnemer
Reviewed By: majnemer
Subscribers: Quuxplusone, probinson, majnemer, cfe-commits
Differential Revision: https://reviews.llvm.org/D42248
llvm-svn: 323577
|
|
|
|
|
|
| |
gcc recently fixed this bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83546
llvm-svn: 323552
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TemplateTemplateParmDecls of alias templates
TemplateTemplateParmDecls of alias templates ended-up serialized as 'file-level decls' which was causing a crash while trying to index a PCH/module file that contained them.
Commit makes sure TemplateTemplateParmDecls are not recorded as such kind of decls.
Fixes crash of rdar://36608297
Differential Revision: https://reviews.llvm.org/D42588
llvm-svn: 323549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for mangling ObjC protocol conformances in MS ABI as if they are
COM interfaces. By diverging from the itanium mangling of `objc_protocol`
prefixed names, this approach allows for a semi-reasonable, albeit of
questionable sanity, undecoration via existing tooling. There is also the
possibility of adding an extension and taking part of the namespace to add the
conformance via the `L` and `Z` "modifiers", but the existing tooling would not
be able to properly undecorated the symbol even though incidentally `undname`
currently produces something legible while wine's implementation is not able to
cope with the extension.
This allows for the disambiguation of overloads where the parameter differs
only in the protocol conformance of the ObjC type, e.g.
```
@protocol P;
void f(std::vector<id>);
void f(std::vector<id<P>>);
```
which clang would previously fail due to the mangling being identical as the
protocol conformance was ignored.
llvm-svn: 323547
|
|
|
|
| |
llvm-svn: 323543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
JavaScript automatic semicolon insertion can trigger before [ and (, so
avoid breaking before them if the previous token is likely to terminate
an expression.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42570
llvm-svn: 323532
|
|
|
|
|
|
|
|
| |
We can stash the cached transparent tag bit in existing pointer padding.
Everything coming out of ASTContext is always aligned to a multiple of
8, so we have 8 spare bits.
llvm-svn: 323528
|
|
|
|
| |
llvm-svn: 323524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also, a number of style and bug fixes was done:
* ASTImporterTest: added sanity check for source node
* ExternalASTMerger: better lookup for template specializations
* ASTImporter: don't add templated declarations into DeclContext
* ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations
* ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc
Differential Revision: https://reviews.llvm.org/D42301
llvm-svn: 323519
|
|
|
|
|
|
| |
"in in" -> "in", "on on" -> "on" etc.
llvm-svn: 323509
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D42276
llvm-svn: 323485
|
|
|
|
|
|
| |
Inline the single use variable into the only use. NFC.
llvm-svn: 323461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For /arch:AVX512F:
clang-cl and cl.exe both defines __AVX512F__ __AVX512CD__.
clang-cl also defines __AVX512ER__ __AVX512PF__.
64-bit cl.exe also defines (according to /Bz) _NO_PREFETCHW.
For /arch:AVX512:
clang-cl and cl.exe both define
__AVX512F__ __AVX512CD__ __AVX512BW__ __AVX512DQ__ __AVX512VL__.
64-bit cl.exe also defines _NO_PREFETCHW.
So not 100% identical, but pretty close.
Also refactor the existing AVX / AVX2 code to not repeat itself in both the
32-bit and 64-bit cases.
https://reviews.llvm.org/D42538
llvm-svn: 323433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r213083 initially implemented /arch: support by mapping it to CPU features.
Then r241077 additionally mapped it to CPU, which made the feature flags
redundant (if harmless). This change here removes the redundant mapping to
feature flags, and rewrites test/Driver/cl-x86-flags.c to be a bit more of an
integration test that checks for preprocessor defines like AVX (like documented
on MSDN) instead of for driver flags.
To keep emitting warn_drv_unused_argument, use getLastArgNoClaim() followed by an explicit claim() if needed.
This is in preparation for adding support for /arch:AVX512(F).
No intended behavior change.
https://reviews.llvm.org/D42497
llvm-svn: 323426
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D41539
llvm-svn: 323421
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Consider the text proto:
```
message {
sub { key: value }
}
```
Previously the first `{` was TT_Unknown, which caused the inner message to be
indented by the continuation width. This didn't happen for:
```
message {
sub: { key: value }
}
```
This is because the code to mark the first `{` as a TT_DictLiteral was only
considering the case where it marches forward and reaches a `:`.
This patch updates this by looking not only for `:`, but also for `<` and `{`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42500
llvm-svn: 323419
|
|
|
|
|
|
|
|
|
|
|
| |
r317337 missed that scudo is supported on MIPS32, so permit that option for
MIPS32.
Reviewers: cryptoad, atanasyan
Differential Revision: https://reviews.llvm.org/D42416
llvm-svn: 323412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As NetBSD, FreeBSD needs execinfo for backtrace's matters.
Patch by: David CARLIER.
Reviewers: joerg, vitalybuka
Reviewed By: vitalybuka
Subscribers: emaste, krytarowski, cfe-commits
Differential Revision: https://reviews.llvm.org/D42467
llvm-svn: 323387
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not attempt to get the pointee of void* while generating a bug report
(otherwise it will trigger an assert inside RegionStoreManager::getBinding
assert(!T->isVoidType() && "Attempting to dereference a void pointer!")).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D42396
llvm-svn: 323382
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Use corutine function arguments to initialize a promise type, but only
if the promise type defines a constructor that takes those arguments.
Otherwise, fall back to the default constructor.
Test Plan: check-clang
Reviewers: rsmith, GorNishanov, eric_niebler
Reviewed By: GorNishanov
Subscribers: toby-allsopp, lewissbaker, EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D41820
llvm-svn: 323381
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows the analyzer to analyze ("inline") custom operator new() calls and,
even more importantly, inline constructors of objects that were allocated
by any operator new() - not necessarily a custom one.
All changes in the tests in the current commit are intended improvements,
even if they didn't carry any explicit FIXME flag.
It is possible to restore the old behavior via
-analyzer-config c++-allocator-inlining=false
(this flag is supported by scan-build as well, and it can be into a clang
--analyze invocation via -Xclang .. -Xclang ..). There is no intention to
remove the old behavior for now.
Differential Revision: https://reviews.llvm.org/D42219
rdar://problem/12180598
llvm-svn: 323373
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I.e. not after. In the c++-allocator-inlining=true mode, we need to make the
assumption that the conservatively evaluated operator new() has returned a
non-null value. Previously we did this on CXXNewExpr, but now we have to do that
before calling the constructor, because some clever constructors are sometimes
assuming that their "this" is null and doing weird stuff. We would also crash
upon evaluating CXXNewExpr when the allocator was inlined and returned null and
had a throw specification; this is UB even for custom allocators, but we still
need not to crash.
Added more FIXME tests to ensure that eventually we fix calling the constructor
for null return values.
Differential Revision: https://reviews.llvm.org/D42192
llvm-svn: 323370
|
|
|
|
|
|
|
|
|
| |
The MSVC runtime library does not provide a definition of wmemcmp,
so we need an inline implementation.
Differential Revision: https://reviews.llvm.org/D42441
llvm-svn: 323362
|
|
|
|
|
|
|
|
| |
Hidden visibility is almost the opposite of dllimport. We were
producing them before (dllimport wins in the existing llvm
implementation), but now the llvm verifier produces an error.
llvm-svn: 323361
|
|
|
|
| |
llvm-svn: 323360
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42428
llvm-svn: 323347
|
|
|
|
|
|
|
|
|
|
|
|
| |
NVPTX does not have runtime support necessary for profiling to work
and even call arc collection is prohibitively expensive. Furthermore,
there's no easy way to collect the samples. NVPTX also does not
support global constructors that clang generates if sample/arc collection
is enabled.
Differential Revision: https://reviews.llvm.org/D42452
llvm-svn: 323345
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Commonly string literals in protos are already multiline, so breaking them
further is undesirable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42373
llvm-svn: 323319
|
|
|
|
| |
llvm-svn: 323316
|
|
|
|
| |
llvm-svn: 323294
|
|
|
|
| |
llvm-svn: 323293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is to fix the bug reported in https://bugs.llvm.org/show_bug.cgi?id=34347#c6.
Currently, all MaxAtomicInlineWidth of x86-32 targets are set to 64. However,
i386 doesn't support any cmpxchg related instructions. i486 only supports cmpxchg.
So in this patch MaxAtomicInlineWidth is reset as follows:
For i386, the MaxAtomicInlineWidth should be 0 because no cmpxchg is supported.
For i486, the MaxAtomicInlineWidth should be 32 because it supports cmpxchg.
For others 32 bits x86 cpu, the MaxAtomicInlineWidth should be 64 because of cmpxchg8b.
Differential Revision: https://reviews.llvm.org/D42154
llvm-svn: 323281
|
|
|
|
|
|
|
|
| |
We would previously treat `SEL` as a pointer-only type. This is not the
case. It should be treated similarly to `id` and `Class`. Add some
test cases to ensure that it will be properly handled as well.
llvm-svn: 323257
|
|
|
|
|
|
|
| |
MaxAtomicPromoteWidth and MaxAtomicInlineWidth are 64 on both
wasm32 and wasm64, so they can be set in shared code.
llvm-svn: 323253
|
|
|
|
|
|
|
|
| |
label attached
Differential Revision: https://reviews.llvm.org/D42320
llvm-svn: 323251
|