| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.
llvm-svn: 262506
|
| |
|
|
| |
llvm-svn: 262503
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17780
llvm-svn: 262499
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
... and register them with CUDA runtime.
This is needed for commonly used cudaMemcpy*() APIs that use address of
host-side shadow to access their counterparts on device side.
Fixes PR26340
Differential Revision: http://reviews.llvm.org/D17779
llvm-svn: 262498
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.
Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)
http://reviews.llvm.org/D17799
llvm-svn: 262493
|
| |
|
|
|
|
|
| |
location as we cannot assume the location of the input file to be
writable.
llvm-svn: 262487
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17706
llvm-svn: 262481
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17699
llvm-svn: 262471
|
| |
|
|
|
|
|
|
|
|
|
| |
Sema allows max values up to 2**28, use unsigned instead of unsiged
short to hold values that large.
Differential Revision: http://reviews.llvm.org/D17248
Patch by Don Hinton!
llvm-svn: 262466
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17794
llvm-svn: 262463
|
| |
|
|
|
|
|
|
| |
OpenMP 4.5 allows to privatize non-static data members of current class
in non-static member functions. Patch supports codegen for non-static
data members in 'reduction' clauses.
llvm-svn: 262460
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change just adds tests for some corner cases of dllimport/dllexport,
primarily for some static methods.
We plan to enable dllimport/dllexport support for the PS4, and these
additional tests are for points we previously were testing internally.
-Warren Ristow
SN Systems - Sony Computer Entertainment Group
Reviewers: rnk
Subscribers: silvas
Differential Revision: http://reviews.llvm.org/D17775
llvm-svn: 262442
|
| |
|
|
|
|
| |
This is useful when paired with the distribution targets to build prerequisites for running tests.
llvm-svn: 262429
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the gcc precompiled header model, one explicitly runs clang with `-x
c++-header` on a .h file to produce a gch file, and then includes the header
with `-include foo.h` and if a .gch file exists for that header it gets used.
This is documented at
http://clang.llvm.org/docs/UsersManual.html#precompiled-headers
cl.exe's model is fairly different, and controlled by the two flags /Yc and
/Yu. A pch file is generated as a side effect of a regular compilation when
/Ycheader.h is passed. While the compilation is running, the compiler keeps
track of #include lines in the main translation unit and writes everything up
to an `#include "header.h"` line into a pch file. Conversely, /Yuheader.h tells
the compiler to skip all code in the main TU up to and including `#include
"header.h"` and instead load header.pch. (It's also possible to use /Yc and /Yu
without an argument, in that case a `#pragma hrdstop` takes the role of
controlling the point where pch ends and real code begins.)
This patch implements limited support for this in that it requires the pch
header to be passed as a /FI force include flag – with this restriction,
it can be implemented almost completely in the driver with fairly small amounts
of code. For /Yu, this is trivial, and for /Yc a separate pch action is added
that runs before the actual compilation. After r261774, the first failing
command makes a compilation stop – this means if the pch fails to build the
main compilation won't run, which is what we want. However, in /fallback builds
we need to run the main compilation even if the pch build fails so that the
main compilation's fallback can run. To achieve this, add a ForceSuccessCommand
that pretends that the pch build always succeeded in /fallback builds (the main
compilation will then fail to open the pch and run the fallback cl.exe
invocation).
If /Yc /Yu are used in a setup that clang-cl doesn't implement yet, clang-cl
will now emit a "not implemented yet; flag ignored" warning that can be
disabled using -Wno-clang-cl-pch.
Since clang-cl doesn't yet serialize some important things (most notably
`pragma comment(lib, ...)`, this feature is disabled by default and only
enabled by an internal driver flag. Once it's more stable, this internal flag
will disappear.
(The default stdafx.h setup passes stdafx.h as explicit argument to /Yc but not
as /FI – instead every single TU has to `#include <stdafx.h>` as first thing it
does. Implementing support for this should be possible with the approach in
this patch with minimal frontend changes by passing a --stop-at / --start-at
flag from the driver to the frontend. This is left for a follow-up. I don't
think we ever want to support `#pragma hdrstop`, and supporting it with this
approach isn't easy: This approach relies on the driver knowing the pch
filename in advance, and `#pragma hdrstop(out.pch)` can set the output
filename, so the driver can't know about it in advance.)
clang-cl now also honors /Fp and puts pch files in the same spot that cl.exe
would put them, but the pch file format is of course incompatible. This has
ramifications on /fallback, so /Yc /Yu aren't passed through to cl.exe in
/fallback builds.
http://reviews.llvm.org/D17695
llvm-svn: 262420
|
| |
|
|
|
|
| |
equivalent tests
llvm-svn: 262418
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARC ownership-convention function type modifications.
According to the Itanium ABI, vendor extended qualifiers are
supposed to be mangled in reverse-alphabetical order before
any CVR qualifiers. The ARC function type conventions are
plausibly order-significant (they are associated with the
function type), which permits us to ignore the need to correctly
inter-order them with any other vendor qualifiers on the parameter
and return types.
Implementing these rules correctly is technically an ABI break.
Apple is comfortable with the risk of incompatibility here for
the ARC features, and I believe that address-space qualification
is still uncommon enough to allow us to adopt the conforming
rule without serious risk. Still, targets which make heavy
use of address space qualification may want to revert to the
non-conforming order.
llvm-svn: 262414
|
| |
|
|
|
|
|
| |
This should fix clang-cmake-mips builder since MIPS does not have IAS enabled
by default (yet).
llvm-svn: 262409
|
| |
|
|
|
|
| |
Patch by Erik Kessler, thank you.
llvm-svn: 262402
|
| |
|
|
|
|
|
|
|
|
| |
popcntintrin.h.
The doxygen comments are automatically generated based on Sony's intrinsics documentation.
Differential Revision: http://reviews.llvm.org/D17550
llvm-svn: 262385
|
| |
|
|
|
|
| |
SEH doesn't use landingpads anymore.
llvm-svn: 262382
|
| |
|
|
|
|
|
|
|
| |
We'd lose track of the parent CodeGenFunction, leading us to get
confused with regard to which function a nested finally belonged to.
Differential Revision: http://reviews.llvm.org/D17752
llvm-svn: 262379
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vec_vsx_st intrinsics
Issue: https://llvm.org/bugs/show_bug.cgi?id=26720
Fix compile error when building ffmpeg for PowerPC64LE because of some
vec_vsx_ld/vec_vsx_st intrinsics are not supported by current clang.
New added intrinsics:
(vector) {signed|unsigned} {short|char} vec_vsx_ld: (total: 8)
bool vec_vsx_ld: (total: 1)
(vector) {signed|unsigned} {short|char} vec_vsx_st: (total: 8)
bool vec_vsx_st: (total: 1)
Total: 18 intrinsics
Phabricator: http://reviews.llvm.org/D17637
llvm-svn: 262359
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17714
llvm-svn: 262355
|
| |
|
|
|
|
|
| |
This should fix clang-cmake-mips builder since MIPS does not have IAS enabled
by default (yet).
llvm-svn: 262350
|
| |
|
|
| |
llvm-svn: 262341
|
| |
|
|
| |
llvm-svn: 262340
|
| |
|
|
|
|
| |
bars on an external compiler-rt build
llvm-svn: 262336
|
| |
|
|
| |
llvm-svn: 262335
|
| |
|
|
|
|
| |
COMPILER_RT_SRC_ROOT doesn't exist.
llvm-svn: 262334
|
| |
|
|
| |
llvm-svn: 262329
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17718
llvm-svn: 262326
|
| |
|
|
|
|
| |
in the test.
llvm-svn: 262325
|
| |
|
|
| |
llvm-svn: 262324
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a commonly useful feature to have, and we have implemented it
multiple times with different kinds of bugs. This implementation
centralizes the idea in a set of functions that we can then use from the various
tools.
Reverts r262234, which is a revert of r262232, and puts the functions
into FOrmat.h, as they are closely coupled to clang-format, and we
otherwise introduce a cyclic dependency between libFormat and
libTooling.
Patch by Eric Liu.
llvm-svn: 262323
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17693
llvm-svn: 262321
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This behavior is enabled when the new CXTranslationUnit_KeepGoing
option is passed to clang_parseTranslationUnit{,2}. It is geared
towards use by IDEs and similar consumers of the clang-c API where
fatal errors may arise when parsing incomplete code mid-edit, or
when include paths are not properly configured yet. In such situations
one still wants to get as much information as possible about a TU.
Previously, the semantic analysis would not instantiate templates
or report additional fatal errors after the first fatal error was
encountered.
Fixes PR24268.
Patch by Milian Wolff.
llvm-svn: 262318
|
| |
|
|
| |
llvm-svn: 262311
|
| |
|
|
| |
llvm-svn: 262308
|
| |
|
|
|
|
| |
related test.
llvm-svn: 262295
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ternary expressions.
Before:
return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ? aaaaa : bbbbbbbbbbbbbbb +
cccccccccccccccc;
After:
return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?
aaaaa :
bbbbbbbbbbbbbbb + cccccccccccccccc;
llvm-svn: 262293
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[aaaaaaaaaaaaaaaaaaaaaaa]
[a].aaaaaaaaaaaaaaaaaaaaaa();
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[aaaaaaaaaaaaaaaaaaaaaaa][a]
.aaaaaaaaaaaaaaaaaaaaaa();
llvm-svn: 262292
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
var x = {
a: a,
b: b, 'c': c,
};
After:
var x = {
a: a,
b: b,
'c': c,
};
llvm-svn: 262291
|
| |
|
|
|
|
| |
expressions, during indexing.
llvm-svn: 262290
|
| |
|
|
| |
llvm-svn: 262289
|
| |
|
|
| |
llvm-svn: 262288
|
| |
|
|
|
|
|
| |
-bitcode_bundle is only passed to the darwin ld64 linker and it is only
implemented there. Remove the check on the linker flag.
llvm-svn: 262286
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Really all these tests are checking is that we find a file path. The
behavior when we don't find one will have `"ps4-ld"` in it. We just need
a path separator to know that a path has been found.
The root cause of the flakiness of these tests is the same on Windows
and non-Windows: setting the PATH environment variable is not sufficient
to guarantee that a particular path is looked up first.
Driver::GetProgramPath checks some paths before deferring to PATH
(in particular, the directory containing the clang binary itself).
I initally ran into this on Windows when putting a PS4 linker in
build-dir/bin/ps4-ld for testing.
After digging for a while thinking that it was some windows path search
oddity (the Windows SearchPathW documentation indicates that its
behavior varies depending on a registry setting...).
I eventually tried reproducing the issue on Mac and to my surprise found
the same issue.
Ultimately I traced it down to the extra lookups in
Driver::GetProgramPath.
llvm-svn: 262285
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is the clang driver part of the change to embedded bitcode. This
includes:
1. -fembed-bitcode option which breaks down the compilation into two
stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.
2. -fembed-bitcode-marker option which doesn't really break down to
two stages to speedup the compilation flow.
3. pass the correct linker flag to darwin linker if tool chains supports
embedded bitcode.
Reviewers: rsmith, thakis
Subscribers: thakis, cfe-commits
Differential Revision: http://reviews.llvm.org/D17390
llvm-svn: 262282
|
| |
|
|
|
|
|
|
|
| |
to allow arbitrary data to be associated with a parameter.
Also, fix a bug where we apparently haven't been serializing
this information for the last N years.
llvm-svn: 262278
|
| |
|
|
|
|
|
| |
Update the diagnostic for classes missing -dealloc to mention an instance
variable that needs to be released.
llvm-svn: 262277
|