| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
These methods weren't really throwing errors. The only error used
was that a file could not be found, which isn't really an error at all
as we are searching paths and libraries for a file. All of the callers
also ignored errors and just used the returned path if one was available.
Changing to return Optional<StringRef> as that actually reflects what
we are trying to do here: optionally find a given path.
llvm-svn: 264979
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264978
|
|
|
|
|
|
| |
Thanks to Rui for pointing out this warning was firing.
llvm-svn: 264977
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As discussed on llvm-dev[1].
This change adds the basic boilerplate code around having this intrinsic
in LLVM:
- Changes in Intrinsics.td, and the IR Verifier
- A lowering pass to lower @llvm.experimental.guard to normal
control flow
- Inliner support
[1]: http://lists.llvm.org/pipermail/llvm-dev/2016-February/095523.html
Reviewers: reames, atrick, chandlerc, rnk, JosephTremoulet, echristo
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18527
llvm-svn: 264976
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the call to the function was valid. For example, in C:
int foo();
int a = foo(1);
Prior to this patch, we'd get an ICE if foo had an enable_if attribute,
because CheckEnableIf assumes that the number of arguments it gets
passed is valid for the function it's passed. Now, we check that the
number of args looks valid prior to checking enable_if conditions.
This fix was not done inside of CheckEnableIf because the problem
presently can only occur in one caller of CheckEnableIf (ActOnCallExpr).
Additionally, checking inside of CheckEnableIf would make us emit
multiple diagnostics for the same error (one "enable_if failed", one
"you gave this function the wrong number of arguments"), which seems
worse than just complaining about the latter.
llvm-svn: 264975
|
|
|
|
|
|
|
|
| |
These methods were responsible for some of the few remaining calls
to llvm::errorCodeToError. Converting them makes us have more Error's
in the api and fewer error_code's.
llvm-svn: 264974
|
|
|
|
| |
llvm-svn: 264973
|
|
|
|
| |
llvm-svn: 264972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current ModuleDependencyCollector has a AST listener to collect
header files present in loaded modules, but this isn't enough to collect
all headers needed in the crash reproducer. One of the reasons is that
the AST writer doesn't write symbolic link header paths in the pcm modules,
this makes the listeners on the reader only able to collect the real files.
Since the module maps could contain submodules that use headers which
are symbolic links, not collecting those forbid the reproducer scripts
to regen the modules.
For instance:
usr/include/module.map:
...
module pthread {
header "pthread.h"
export *
module impl {
header "pthread_impl.h"
export *
}
}
...
usr/include/pthread/pthread_impl.h
usr/include/pthread_impl.h -> pthread/pthread_impl.h
The AST dump for the module above:
<SUBMODULE_HEADER abbrevid=6/> blob data = 'pthread_impl.h'
<SUBMODULE_TOPHEADER abbrevid=7/> blob data = '/<path_to_sdk>/usr/include/pthread/pthread_impl.h'
Note that we don't have "usr/include/pthread_impl.h" which is requested
by the module.map in case we want to reconstruct the module in the
reproducer. The reason the original symbolic link path isn't used is
because the headers are kept by name and requested through the
FileManager, which unique files and returns the real path only.
To fix that, add a callback to be invoked everytime a header is added
while parsing module maps and hook that up to the module dependecy
collector. This callback is only registered when generating the
reproducer.
Differential Revision: http://reviews.llvm.org/D18585
rdar://problem/24499339
llvm-svn: 264971
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The VFS YAML files contain empty directory entries to describe that it's
returning from a subdirectory before describing new files in the parent.
In the future, we should properly sort and write YAML files avoiding
such empty dirs and mitigate the extra recurson cost. However, since
this is used by previous existing YAMLs, make the traversal work in
their presence.
rdar://problem/24499339
llvm-svn: 264970
|
|
|
|
|
|
|
|
| |
We already have this flag in most of the file, but we need it everywhere
else, to disable the NVVMReflect pass, which we're explicitly checking
doesn't run here. (Upcoming changes to llvm will cause it to be run.)
llvm-svn: 264969
|
|
|
|
|
|
|
| |
This converts almost all of the error handling in atom creation
to llvm::Error instead of std::error_code.
llvm-svn: 264968
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
__atomic_load's allows it's first argument to be a pointer to a const type. However the second argument is an output parameter and must be a pointer to non-const.
This patch fixes the signature of __atomic_load generated by clang so that it respects the above requirements.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13420
llvm-svn: 264967
|
|
|
|
|
|
|
|
|
|
| |
(PR26325)
The size savings are significant, and from what I can tell, both ICC and GCC do this.
Differential Revision: http://reviews.llvm.org/D18573
llvm-svn: 264966
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This prevents errors when you invoke clang with a flag that the NVPTX
toolchain doesn't support. For example, on x86-64,
clang -mthread-model single -x c++ /dev/null -o /dev/null
should output just one error about "invalid thread model 'single' in
'-mthread-model single' for this target"; x86-64 doesn't support
-mthread-model, but we shouldn't also instantiate a NVPTX target!
Reviewers: echristo
Subscribers: tra, sunfish, cfe-commits
Differential Revision: http://reviews.llvm.org/D18629
llvm-svn: 264965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, by a constexpr function is implicitly host+device
unless:
a) it's a variadic function (variadic functions are not allowed on the
device side), or
b) it's preceeded by a __device__ overload in a system header.
The restriction on overloading __host__ __device__ functions on the
basis of their CUDA attributes remains in place, but we use (b) to allow
us to define __device__ overloads for constexpr functions in cmath,
which would otherwise be __host__ __device__ and thus not overloadable.
You can disable this behavior with -fno-cuda-host-device-constexpr.
Reviewers: tra, rnk, rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D18380
llvm-svn: 264964
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is necessary for a future patch which will make all constexpr
functions implicitly host+device. cmath may declare constexpr
functions, but these we do *not* want to be host+device. The forward
declares added in this patch prevent this (because the rule will be,
constexpr functions become implicitly host+device unless they're
preceeded by a decl with __device__).
Reviewers: tra
Subscribers: cfe-commits, rnk, rsmith
Differential Revision: http://reviews.llvm.org/D18539
llvm-svn: 264963
|
|
|
|
|
|
|
|
|
|
| |
This is breaking http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/31647/steps/test%20lld/logs/stdio.
The issue seems to be that it can't write to a file in /tmp, probably because that path doesn't
exist on Windows. This was failing after I added EXPECT_FALSE(ec) in r264961 for the error
handling migration.
llvm-svn: 264962
|
|
|
|
|
|
|
| |
This converts the writeFile method, as well as some of the ones it calls
in the normalized binary file writer and yaml writer.
llvm-svn: 264961
|
|
|
|
| |
llvm-svn: 264960
|
|
|
|
| |
llvm-svn: 264959
|
|
|
|
| |
llvm-svn: 264958
|
|
|
|
|
|
| |
no formatters matching the constraints could be found
llvm-svn: 264957
|
|
|
|
|
|
|
|
|
|
|
| |
If we make R_MIPS_LO16 a relative relocation, linker:
- never creates R_MIPS_COPY relocation for it
- attempts to create R_MIPS_REL32 dynamic relocation if R_MIPS_LO16's
target is a preemptible symbol
Differential Revision: http://reviews.llvm.org/D18607
llvm-svn: 264956
|
|
|
|
| |
llvm-svn: 264955
|
|
|
|
| |
llvm-svn: 264954
|
|
|
|
| |
llvm-svn: 264953
|
|
|
|
| |
llvm-svn: 264952
|
|
|
|
| |
llvm-svn: 264951
|
|
|
|
| |
llvm-svn: 264950
|
|
|
|
| |
llvm-svn: 264949
|
|
|
|
| |
llvm-svn: 264948
|
|
|
|
| |
llvm-svn: 264947
|
|
|
|
| |
llvm-svn: 264946
|
|
|
|
| |
llvm-svn: 264945
|
|
|
|
| |
llvm-svn: 264944
|
|
|
|
| |
llvm-svn: 264943
|
|
|
|
| |
llvm-svn: 264942
|
|
|
|
| |
llvm-svn: 264941
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://llvm.org/bugs/show_bug.cgi?id=27129 which is crash involving type
aliases and template type diffing. Template arguments for type aliases and
template arguments for the underlying desugared type may not have one-to-one
relations, which could mess us the attempt to get more information from the
desugared type. For type aliases, ignore the iterator over the desugared type.
llvm-svn: 264940
|
|
|
|
| |
llvm-svn: 264939
|
|
|
|
|
|
|
| |
This test should fail on OS X Yosemite and older, and pass on OS X El Capitan
and newer as well as on other platforms.
llvm-svn: 264938
|
|
|
|
|
|
|
|
|
|
| |
underlying type.
Fixes https://llvm.org/bugs/show_bug.cgi?id=26014
Reviewed by Richard Smith.
llvm-svn: 264937
|
|
|
|
|
|
|
| |
r264884 introduced a helper to escape the backslashes in the source file
path, but I since discovered an existing mechanism to escape strings.
llvm-svn: 264936
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit r260791 contained an error in that it would introduce a cross-module
reference in the old module. It also introduced O(N^2) complexity in the
module cloner by requiring the entire module to be visited for each function.
Fix both of these problems by avoiding use of the CloneDebugInfoMetadata
function (which is only designed to do intra-module cloning) and cloning
function-attached metadata in the same way that we clone all other metadata.
Differential Revision: http://reviews.llvm.org/D18583
llvm-svn: 264935
|
|
|
|
|
|
|
|
| |
#endif was one line too low. If KMP_USE_ADAPTIVE_LOCKS is 0,
then queuing locks would incorrectly use drdpa lock mechanism.
This is a fix for https://llvm.org/bugs/show_bug.cgi?id=26649
llvm-svn: 264934
|
|
|
|
| |
llvm-svn: 264933
|
|
|
|
|
|
| |
"C4334 '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)". NFC.
llvm-svn: 264932
|
|
|
|
|
|
| |
This is identical to the other r600 datalayout string.
llvm-svn: 264931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
compilation error or crash
Summary:
When the code is compiled for arm32 and the builtin `__va_list` declaration is created by `CreateAAPCSABIBuiltinVaListDecl`, the declaration is not saved in the `ASTContext` which may lead to a compilation error or crash.
Minimal reproducer I was able to find:
**header.h**
```
#include <stdarg.h>
typedef va_list va_list_1;
```
**test.cpp**
```
typedef __builtin_va_list va_list_2;
void foo(const char* format, ...) { va_list args; va_start( args, format ); }
```
Steps to reproduce:
```
clang -x c++-header --target=armv7l-linux-eabihf header.h
clang -c -include header.h --target=armv7l-linux-eabihf test.cpp
```
Compilation error:
```
error: non-const lvalue reference to type '__builtin_va_list'
cannot bind to a value of unrelated type 'va_list' (aka '__builtin_va_list')
```
Compiling the same code as a C source leads to a crash:
```
clang --target=armv7l-linux-eabihf header.h
clang -c -x c -include header.h --target=armv7l-linux-eabihf test.cpp
```
Reviewers: logan, rsmith
Subscribers: cfe-commits, asl, aemerson, rengolin
Differential Revision: http://reviews.llvm.org/D18557
llvm-svn: 264930
|