| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
We were checking the value after truncating it to a bitfield.
Thanks to Yunzhong Gao for noticing it.
llvm-svn: 224378
|
| |
|
|
|
|
|
|
| |
we'll do spell checking. Note that spell checking will change the produced AST, so we don't automatically change this value when someone sets -ferror-limit=. With this, merge test typo-correction-pt2.cpp into typo-correction.cpp.
Remove Sema::UnqualifiedTyposCorrected, a cache of corrected typos. It would only cache typo corrections that didn't provide ValidateCandidate of which there were few left, and it had a bug when we had the same identifier spelled wrong twice. See the last two tests in typo-correction.cpp for cases this fires.
llvm-svn: 224375
|
| |
|
|
|
|
|
| |
Bitfield RefersToEnclosingLocal of Stmt::DeclRefExprBitfields renamed to RefersToCapturedVariable to reflect latest changes introduced in commit 224323. Also renamed method Expr::refersToEnclosingLocal() to Expr::refersToCapturedVariable() and comments for constant arguments.
No functional changes.
llvm-svn: 224329
|
| |
|
|
|
|
|
|
| |
Currently, if global variable is marked as a private OpenMP variable, the compiler crashes in debug version or generates incorrect code in release version. It happens because in the OpenMP region the original global variable is used instead of the generated private copy. It happens because currently globals variables are not captured in the OpenMP region.
This patch adds capturing of global variables iff private copy of the global variable must be used in the OpenMP region.
Differential Revision: http://reviews.llvm.org/D6259
llvm-svn: 224323
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Mixed path separators (ie, both / and \\) can mess up the sort order
of the VFS map when dumping module dependencies, as was recently
exposed by r224055 and papered over in r224145. Instead, we should
simply use native paths for consistency.
This also adds a TODO to add handling of .. in paths. There was some
code for this before r224055, but it was untested and probably broken.
llvm-svn: 224164
|
| |
|
|
|
|
|
| |
components. These sometimes get synthetically added, and we don't want -Ifoo
and -I./foo to be treated fundamentally differently here.
llvm-svn: 224055
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
arithmetic relaxation flags:
-cl-no-signed-zeros
-cl-unsafe-math-optimizations
-cl-finite-math-only
-cl-fast-relaxed-math
Propagate the info to FP instruction flags as well
as function attributes where they are available.
llvm-svn: 223928
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
llvm-svn: 223927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223913
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r223753. It broke the Green Dragon build for a few
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c
I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.
llvm-svn: 223759
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
|
| |
|
|
|
|
| |
complain that the contained modules are defined twice.
llvm-svn: 223724
|
| |
|
|
|
|
| |
diagnostics if they don't exist. Based on a patch by John Thompson!
llvm-svn: 223561
|
| |
|
|
|
|
| |
against an enum.
llvm-svn: 223422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Allow CUDA host device functions with two code paths using __CUDA_ARCH__
to differentiate between code path being compiled.
For example:
__host__ __device__ void host_device_function(void) {
#ifdef __CUDA_ARCH__
device_only_function();
#else
host_only_function();
#endif
}
Patch by Jacques Pienaar.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D6457
llvm-svn: 223271
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
rather than trying to extract this information from the FileEntry after the
fact.
This has a number of beneficial effects. For instance, diagnostic messages for
failed module builds give a path relative to the "module root" rather than an
absolute file path, and the contents of the module includes file is no longer
dependent on what files the including TU happened to inspect prior to
triggering the module build.
llvm-svn: 223095
|
| |
|
|
|
|
|
| |
This suppresses the implicit search for files called 'module.modulemap' and
similar.
llvm-svn: 222745
|
| |
|
|
|
|
|
| |
This option sets language mode for the compilation of a source file to be OpenCL v2.0.
Example: clang -cc1 -cl-std=CL2.0 myfile.cl
llvm-svn: 222444
|
| |
|
|
|
|
| |
pair<iterator, bool> as per the C++ standard's associative container concept.
llvm-svn: 222335
|
| |
|
|
| |
llvm-svn: 222306
|
| |
|
|
| |
llvm-svn: 222303
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Make DiagnosticsEngine::takeClient return std::unique_ptr<>. Updated
callers to store conditional ownership using a pair of pointer and unique_ptr
instead of a pointer + bool. Updated code that temporarily registers clients to
use the non-owning registration (+ removed extra calls to takeClient).
Reviewers: dblaikie
Reviewed By: dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6294
llvm-svn: 222193
|
| |
|
|
| |
llvm-svn: 222130
|
| |
|
|
| |
llvm-svn: 222042
|
| |
|
|
| |
llvm-svn: 222024
|
| |
|
|
|
|
|
|
|
| |
This option was misleading because it looked like it enabled the
language feature of SEH (__try / __except), when this option was really
controlling which EH personality function to use. Mingw only supports
SEH and SjLj EH on x86_64, so we can simply do away with this flag.
llvm-svn: 221963
|
| |
|
|
|
|
|
|
|
|
| |
This fixes an assertion when running clang-tidy on a file having
--serialize-diagnostics in compiler options. Committing a regression test
for clang-tidy separately.
Patch by Aaron Wishnick!
llvm-svn: 221884
|
| |
|
|
|
|
| |
which we don't yet implement).
llvm-svn: 221816
|
| |
|
|
| |
llvm-svn: 221784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change makes the asan-coverge (formerly -mllvm -asan-coverge)
accessible via a clang flag.
Companion patch to LLVM is http://reviews.llvm.org/D6152
Test Plan: regression tests, chromium
Reviewers: samsonov
Reviewed By: samsonov
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6153
llvm-svn: 221719
|
| |
|
|
|
|
|
|
|
| |
For all threadprivate variables which have constructor/destructor emit call to void __kmpc_threadprivate_register(ident_t * <Current Location>, void *<Original Global Addr>, kmpc_ctor <Constructor>, kmpc_cctor NULL, kmpc_dtor <Destructor>);
In expressions all references to such variables are replaced by calls to void *__kmpc_threadprivate_cached(ident_t *<Current Location>, kmp_int32 <Current Thread Id>, void *<Original Global Addr>, size_t <Size of Data>, void ***<Pointer to autogenerated cache – array of private copies of threadprivate variable>);
Test test/OpenMP/threadprivate_codegen.cpp checks that codegen is correct. Also it checks that codegen is correct after serialization/deserialization and one of passes verifies debug info.
Differential Revision: http://reviews.llvm.org/D4002
llvm-svn: 221663
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of ugly SanitizerOptions class thrust into LangOptions:
* Make SanitizeAddressFieldPadding a regular language option,
and rely on default behavior to initialize/reset it.
* Make SanitizerBlacklistFile a regular member LangOptions.
* Introduce the helper class "SanitizerSet" to represent the
set of enabled sanitizers and make it a member of LangOptions.
It is exactly the entity we want to cache and modify in CodeGenFunction,
for instance. We'd also be able to reuse SanitizerSet in
CodeGenOptions for storing the set of recoverable sanitizers,
and in the Driver to represent the set of sanitizers
turned on/off by the commandline flags.
No functionality change.
llvm-svn: 221653
|
| |
|
|
| |
llvm-svn: 221646
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Use the bitmask to store the set of enabled sanitizers instead of a
bitfield. On the negative side, it makes syntax for querying the
set of enabled sanitizers a bit more clunky. On the positive side, we
will be able to use SanitizerKind to eventually implement the
new semantics for -fsanitize-recover= flag, that would allow us
to make some sanitizers recoverable, and some non-recoverable.
No functionality change.
llvm-svn: 221558
|
| |
|
|
|
|
|
|
| |
,-objcmt-migrate-property-dot-syntax, when migarting to use
property-dot syntax in place of messaging expression.
rdar://18839124
llvm-svn: 221001
|
| |
|
|
|
|
| |
they are not needed.
llvm-svn: 220966
|
| |
|
|
|
|
| |
unit, allow the -O settings of the two compilations to differ.
llvm-svn: 220943
|
| |
|
|
|
|
|
| |
rewriting an Objective-C block. Patch by Ryan Govostes.
rdar://18799145
llvm-svn: 220834
|
| |
|
|
| |
llvm-svn: 220731
|
| |
|
|
|
|
|
|
|
| |
GCC doesn't do this and it semes weird to include a file that we can't
open.
This fixes PR21362.
llvm-svn: 220726
|
| |
|
|
|
|
|
|
|
| |
GCC defines __EXCEPTIONS, regardless of language mode, if -fexceptions
is passed. We should do the same.
This fixes PR21358.
llvm-svn: 220714
|
| |
|
|
|
|
|
| |
This eliminates converting back and forth between the 3 formats and
gives us a more homogeneous interface.
llvm-svn: 220657
|
| |
|
|
| |
llvm-svn: 220543
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
|
| |
|
|
|
|
| |
clangAST.
llvm-svn: 220502
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
When using a profile, we used to require the use -gmlt so that we could
get access to the line locations. This is used to match line numbers in
the input profile to the line numbers in the function's IR.
But this is actually not necessary. The driver can provide source
location tracking without the emission of debug information. In these
cases, the annotation 'llvm.dbg.cu' is missing from the IR, but the
actual line location annotations are still present.
This patch tells the driver to only emit source location tracking
when -fprofile-sample-use is present in the command line.
Reviewers: echristo, dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5888
llvm-svn: 220383
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implicit module builds are not well-suited to a lot of build systems. In
particular, they fare badly in distributed build systems, and they lead to
build artifacts that are not tracked as part of the usual dependency management
process. This change allows explicitly-built module files (which are already
supported through the -emit-module flag) to be explicitly loaded into a build,
allowing build systems to opt to manage module builds and dependencies
themselves.
This is only the first step in supporting such configurations, and it should
be considered experimental and subject to change or removal for now.
llvm-svn: 220359
|
| |
|
|
|
|
| |
This turns out to break our freestanding tests on Windows when compiling in MSVC-compatible mode. It was decided (http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20141020/116942.html is the start of the thread) to support this as part of Clang's interface on all platforms.
llvm-svn: 220312
|
| |
|
|
|
|
|
|
| |
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
|
| |
|
|
|
|
|
|
|
|
|
|
| |
#include_next interacts poorly with modules: it depends on where in the list of
include paths the current file was found. Files covered by module maps are not
found in include search paths when building the module (and are not found in
include search paths when @importing the module either), so this isn't really
meaningful. Instead, we fake up the result that #include_next *should* have
given: find the first path that would have resulted in the given file being
picked, and search from there onwards.
llvm-svn: 220177
|