| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
| |
driving a canonical difference between that and an unqualified
type is a really bad idea when both are valid. Instead, remember
that it was there in a non-canonical way, then look for that in
the one place we really care about it: block captures. The net
effect closely resembles the behavior of a decl attribute, except
still closely following ARC's standard qualifier parsing rules.
llvm-svn: 253534
|
| |
|
|
|
|
|
|
|
| |
to start at the offset of the first ivar instead of the rounded-up
end of the superclass. The latter could include a large amount of
tail padding because of a highly-aligned ivar, and subclass ivars
can be laid out within that.
llvm-svn: 253533
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Conversions between unrelated pointer types (e.g. char * and void *) involve
bitcasts which were not properly modeled in case of static initializers. The
patch fixes this problem.
The problem was originally spotted by Artem Dergachev. Patched by Yuri Gribov!
Differential Revision: http://reviews.llvm.org/D14652
llvm-svn: 253532
|
| |
|
|
|
|
|
|
|
|
|
| |
In the Microsoft ABI, the vftable is laid out in the order in the
declaration order of the entities defined within it.
Obviously, only virtual methods end up in the vftable but they will be
placed into the table at the same position as the first entity with the
same name.
llvm-svn: 253523
|
| |
|
|
|
|
|
|
|
|
|
| |
The conversion from QuantityType to the (temporary) IntegerAlignment class
was ambiguous.
For now add in explicit conversion to unsigned to satisfy the clang-x86_64-debian-fast bot.
I'll remove the explicit conversion when I remove the IntegerAlignment class.
llvm-svn: 253519
|
| |
|
|
|
|
|
|
|
|
|
| |
Since we don't check functions in dependent contexts, we should skip blocks
in those contexts as well. This avoids an assertion failure when the
DeadStoresChecker attempts to evaluate an array subscript expression with
a dependent name type.
rdar://problem/23564220
llvm-svn: 253516
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow on from a similar LLVM commit: r253511.
Note, this was reviewed (and more details are in) http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151109/312083.html
These intrinsics currently have an explicit alignment argument which is
required to be a constant integer. It represents the alignment of the
source and dest, and so must be the minimum of those.
This change allows source and dest to each have their own alignments
by using the alignment attribute on their arguments. The alignment
argument itself is removed.
The only code change to clang is hidden in CGBuilder.h which now passes
both dest and source alignment to IRBuilder, instead of taking the minimum of
dest and source alignments.
Reviewed by Hal Finkel.
llvm-svn: 253512
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We created a malformed TemplateSpecializationType: it was dependent but
had a RecordType as it's canonical type. This would lead getAs to
crash. r249090 worked around this but we should fix this for real by
providing a more appropriate template specialization type as the
canonical type.
This fixes PR24246.
llvm-svn: 253495
|
| |
|
|
|
|
| |
copy-pasta issue that my local testing did not catch.
llvm-svn: 253481
|
| |
|
|
| |
llvm-svn: 253475
|
| |
|
|
|
|
| |
a VarDecl has automatic, static, or thread storage duration. This also updates the documentation for matchers, which appear to be missing some previous additions.
llvm-svn: 253473
|
| |
|
|
| |
llvm-svn: 253471
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14754
llvm-svn: 253467
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This provides both a more uniform interface and makes libclang behave like
clang tooling wrt relative paths against argv[0]. This is necessary for
finding paths to a c++ standard library relative to a clang binary given
in a compilation database. It can also be used to find paths relative to
libclang.so if the full path to it is passed in.
Differential Revision: http://reviews.llvm.org/D14695
llvm-svn: 253466
|
| |
|
|
| |
llvm-svn: 253456
|
| |
|
|
| |
llvm-svn: 253440
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from Unevaluated to ConstantEvaluated.
This patch emits a more appropriate (but still noisy) diagnostic stream when a lambda-expression is encountered within a non-type default argument.
For e.g. template<int N = ([] { return 5; }())> int f();
As opposed to complaining that a lambda expression is not allowed in an unevaluated operand, the patch complains about the lambda being forbidden in a constant expression context (which will be allowed in C++17 now that they have been accepted by EWG, unless of course CWG or national bodies (that have so far shown no signs of concern) rise in protest)
As I start submitting patches for constexpr lambdas (http://wg21.link/P0170R0) under C++1z (OK'd by Richard Smith at Kona), this will be one less change to make.
Thanks!
llvm-svn: 253431
|
| |
|
|
|
|
|
|
| |
unsafe, since many operations on the types can trigger lazy deserialization of
more types and invalidate the iterators. This fixes a crasher, but I've not
been able to reduce it to a reasonable testcase yet.
llvm-svn: 253420
|
| |
|
|
|
|
| |
Return std::string itself instead StringRef to a temporary std::string.
llvm-svn: 253410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when there is a global register variable in a program that
is bound to an invalid register, clang/llvm prints an error message that
is not very user-friendly.
This commit improves the diagnostic and moves the check that used to be
in the backend to Sema. In addition, it makes changes to error out if
the size of the register doesn't match the declared variable size.
e.g., volatile register int B asm ("rbp");
rdar://problem/23084219
Differential Revision: http://reviews.llvm.org/D13834
llvm-svn: 253405
|
| |
|
|
| |
llvm-svn: 253404
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
other than the top level, we issue an error. This breaks a fair amount of C++
code wrapping C libraries, where the C library is #included within a namespace
/ extern "C" combination, because the C library (probably) includes C++
standard library headers which may be within modules.
Without modules, this setup is harmless if (and *only* if) the corresponding
standard library module was already included outside the namespace, so
downgrade the error to a default-error extension in that case, so that it can
be selectively disabled for such misbehaving libraries.
llvm-svn: 253398
|
| |
|
|
| |
llvm-svn: 253390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently clang requires several additional command
line options in order to enable new features needed
during CUDA compilation. This patch makes these
options default.
* Automatically include cuda_runtime.h if we've found
a valid CUDA installation.
* Disable automatic CUDA header inclusion during unit tests.
* Added test case for command line construction.
* Enabled target overloads and relaxed call checks that are
needed in order to include CUDA headers.
* Added CUDA-7.5 installation path to the CUDA installation search list.
* Define __CUDA__ macro to indicate CUDA compilation.
llvm-svn: 253389
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Header files that come with CUDA are assuming split host/device
compilation and are not usable by clang out of the box.
With a bit of preprocessor magic it's possible to twist them
into something clang can use.
This wrapper always includes CUDA headers exactly the same way during
host and device compilation passes and produces identical preprocessed
content during host and device side compilation for sm_35 GPUs. Device
compilation passes for older GPUs will see a smaller subset of device
functions supported by particular GPU.
The wrapper assumes specific contents of CUDA header files and works
only with CUDA 7.0 and 7.5.
Differential Revision: http://reviews.llvm.org/D13171
llvm-svn: 253388
|
| |
|
|
|
|
|
|
|
|
|
| |
- added detection of libdevice bitcode file and API to find one appropriate for the GPU we're compiling for.
- pass additional cc1 options for linking with detected libdevice bitcode
- added -nocudalib to prevent automatic linking with libdevice
- added test cases to verify new functionality
Differential Revision: http://reviews.llvm.org/D14556
llvm-svn: 253387
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to compile a CUDA file clang must be able to find
include files for both both host and device.
This patch passes AuxToolchain to AddPreprocessingOptions and
uses it to add include paths for the opposite side of compilation.
We also must be able to find CUDA include files. If the driver
found CUDA installation, it adds appropriate include path
to CUDA headers. This can be disabled with '-nocudainc'.
- Added include paths for the opposite side of compilation.
- Added include paths to detected CUDA installation.
- Added -nocudainc to prevent adding CUDA include path.
- Added test cases to verify new functionality.
Differential Revision: http://reviews.llvm.org/D13170
llvm-svn: 253386
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Clang needs to know target triple for both sides of compilation so that
preprocessor macros and target builtins from both sides are available.
This change augments Compilation class to carry information about
toolchains used during different CUDA compilation passes and refactors
BuildActions to use it when it constructs CUDA jobs.
Removed DeviceTriple from CudaHostAction/CudaDeviceAction as it's no
longer needed.
Differential Revision: http://reviews.llvm.org/D13144
llvm-svn: 253385
|
| |
|
|
|
|
| |
Thereby fixing a warning about failure to claim all args.
llvm-svn: 253372
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The tzcnt intrinsics are used non non-BMI targets by code (e.g. ffmpeg)
that uses it as a potentially faster BSF.
The TZCNT instruction is special in that it's encoded in a
backward-compatible way and behaves as BSF on non-BMI targets.
Differential Revision: http://reviews.llvm.org/D14748
llvm-svn: 253358
|
| |
|
|
|
|
|
|
|
|
|
|
| |
"-arch armv7k" is only normally used with a watchos target, but Clang doesn't
stop you from giving a "-miphoneos-version-min" option too, converting the
triple to "thumbv7k-apple-ios". In this case the backend will decide to use
SjLj exceptions, so Clang needs to agree so it can create the correct
predefines.
Fortunately, there's a handy function to make the decision for us now.
llvm-svn: 253355
|
| |
|
|
| |
llvm-svn: 253350
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r253269.
This leads to assert / segfault triggering on the following reduced example:
float foo(float U, float base, float cell) { return (U = 2 * base) - cell; }
llvm-svn: 253337
|
| |
|
|
|
|
| |
diagnostics. NFC
llvm-svn: 253316
|
| |
|
|
| |
llvm-svn: 253315
|
| |
|
|
| |
llvm-svn: 253314
|
| |
|
|
|
|
|
| |
declarations that are not simultaneously visible, and where at least one of
them has internal/no linkage.
llvm-svn: 253283
|
| |
|
|
|
|
| |
Differential Revision: D14200
llvm-svn: 253269
|
| |
|
|
|
|
|
| |
It could be derived from gnutools::Linker directly but this way makes it
consistent with all the other toolchains around it.
llvm-svn: 253259
|
| |
|
|
|
|
|
|
| |
peephole I added in r250916.
rdar://23559789
llvm-svn: 253255
|
| |
|
|
|
|
|
|
|
|
| |
target attribute, don't include "negative" subtarget features in the
list of required features. Builtins are positive by default so don't
need this change, but we pull the default list of features from the
command line and so need to make sure that we only include features
that are turned on for code generation in our error.
llvm-svn: 253242
|
| |
|
|
|
|
|
| |
Instead, use the constant "mips" since the libraries are already
placed under the multilib's OS suffix.
llvm-svn: 253214
|
| |
|
|
| |
llvm-svn: 253213
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These two intrinsics are defined in arm_acle.h.
__rev16l needs to rotate by 16 bits, bit it was actually rotating by 2 bits.
For AArch64, where long is 64 bits, this would still be wrong.
__rev16ll was incorrect, it reversed the bytes in each 32-bit word, rather than
each 16-bit halfword. The correct implementation is to apply __rev16 to the top
and bottom words of the 64-bit value.
For AArch32 targets, these get compiled down to the hardware rev16 instruction
at -O1 and above. For AArch64 targets, the 64-bit ones get compiled to two
32-bit rev16 instructions, because there is not currently a pattern for the
64-bit rev16 instruction.
Differential Revision: http://reviews.llvm.org/D14609
llvm-svn: 253211
|
| |
|
|
|
|
|
|
|
| |
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
|
| |
|
|
|
|
|
|
| |
The TargetParser API to get the default FPU and default extensions has
changed so that it can fall back to the architecture in case of a
generic CPU.
llvm-svn: 253199
|
| |
|
|
| |
llvm-svn: 253191
|
| |
|
|
|
|
|
|
|
|
| |
In r253186, I changed the DIBuilder API to now take size and align
for reference types as well. This was done in preparation for upcoming
changes to the Verifier that will validate that sizes match between
DI types and IR values that are declared as having those types.
This updates clang to actually pass the information through.
llvm-svn: 253190
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
is_empty, is_polymorphic, and is_abstract didn't handle incomplete types
correctly. Only non-union class types must be complete for these
traits.
is_final and is_sealed don't care about the particular spelling of the
FinalAttr.
is_interface_class should always return false regardless of its input.
The type trait can only be satisfied in a mode we do not support (/CLR).
llvm-svn: 253184
|
| |
|
|
| |
llvm-svn: 253178
|