This implements something like the current direction of DR1581: we use a narrow
syntactic check to determine the set of places where a constant expression
could be evaluated, and only instantiate a constexpr function or variable if
it's referenced in one of those contexts, or is odr-used.
It's not yet clear whether this is the right set of syntactic locations; we
currently consider all contexts within templates that would result in odr-uses
after instantiation, and contexts within list-initialization (narrowing
conversions take another victim...), as requiring instantiation. We could in
principle restrict the former cases more (only const integral / reference
variable initializers, and contexts in which a constant expression is required,
perhaps). However, this is sufficient to allow us to accept libstdc++ code,
which relies on GCC's behavior (which appears to be somewhat similar to this
approach).
llvm-svn: 291318
Summary:
In order to simplify distributed build system integration, where actions
may be scheduled before the Thin Link which determines the list of
objects selected by the linker. The gold plugin currently will emit
0-sized index files for objects not selected by the link, to enable
checking for expected output files by the build system. If the build
system then schedules a backend action for these bitcode files, we want
to be able to fall back to normal compilation instead of failing.
Fallback is enabled under an option in LLVM (D28410), in which case a
nullptr is returned from llvm::getModuleSummaryIndexForFile. Clang can
just proceed with non-ThinLTO compilation in that case.
I am investigating whether this can be addressed in our build system,
but that is a longer term fix and so this enables a workaround in the
meantime.
Reviewers: mehdi_amini
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28362
llvm-svn: 291303
dependent context and can't be used in a constant expression.
Per C++ [temp.inst]p2, "the instantiation of a static data member does not
occur unless the static data member is used in a way that requires the
definition to exist".
This doesn't /quite/ match that, as we still instantiate static data members
that are usable in constant expressions even if the use doesn't require a
definition. A followup patch will fix that for both variables and functions.
llvm-svn: 291295
Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.
Thanks Aleksey!
This reapplies r291184, reverted in r291249.
llvm-svn: 291270
It passes --sysroot for the Linux CUDA installation. To make this test
pass when targetting Windows, you would need to pass
--sysroot=Inputs/CUDA-windows.
llvm-svn: 291255
FunctionDecls.
This commit silences an incorrect warning that is issued when a function
pointer is cast to another function pointer type. The warning gets
issued because alignments of the source and destination do not match in
Sema::CheckCastAlign, which happens because ASTContext::getTypeInfoImpl
and ASTContext::getDeclAlign return different values for functions (the
former returns 4 while the latter returns 1).
This should fix PR31558.
rdar://problem/29533528
Differential Revision: https://reviews.llvm.org/D27478
llvm-svn: 291253
Summary:
This patch makes the type_mismatch static data 7 bytes smaller (and it
ends up being 16 bytes smaller due to alignment restrictions, at least
on some x86-64 environments).
It revs up the type_mismatch handler version since we're breaking binary
compatibility. I will soon post a patch for the compiler-rt side.
Reviewers: rsmith, kcc, vitalybuka, pgousseau, gbedwell
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D28242
llvm-svn: 291236
Now when completing blocks properties that return void the block call completion
result shows up before the setter, otherwise the setter completion shows up
before the block call completion. We normally want to use the result of the
block call, so one typically wouldn't call a block that returns a non-void type
in a standalone statement.
rdar://28846153
Differential Revision: https://reviews.llvm.org/D26034
llvm-svn: 291232
This change avoids the -Wstrict-prototypes warning for block literals with an
empty argument list or without argument lists.
rdar://15060615
Differential Revision: https://reviews.llvm.org/D28296
llvm-svn: 291231
This test would force the execution of the backend. However, the
backend already has a test for this. Effectively, this was trying to
test that an API call was made properly. We do not have a good way to
really test this. The test itself tested very little.
Addresses post-commit review comments from Eric Christopher.
llvm-svn: 291208
Add builtins for the functions and custom codegen mapping the builtins to their
corresponding intrinsics and handling the endian related swapping.
https://reviews.llvm.org/D26546
llvm-svn: 291179
It seems that the ARM buildbots do not include x86 support. However,
other x86 targets do not support the ARM target. Use a x86 triple and
require the registered target.
llvm-svn: 291142
Summary:
MSVC seems to use "__in" and "__out" for its own purposes, so we have to
pick different names in this macro.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28325
llvm-svn: 291138
Summary:
When compiling device code, we may still see host code with explicit
calling conventions. NVPTX needs to claim that it supports these CCs,
so that (a) we don't raise noisy warnings, and (b) we don't break
existing code which relies on the existence of these CCs when
specializing templates. (If a CC doesn't exist, clang ignores it, so
two template specializations which are different only insofar as one
specifies a CC are considered identical and therefore are an error if
that CC is not supported.)
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28323
llvm-svn: 291136
Summary:
CUDA lets users share structs between the host and device, so for that
and other reasons, primitive types such as ptrdiff_t should be the same
on both sides of the compilation.
Our code to do this wasn't entirely successful. In particular, we did a
bunch of work during the NVPTXTargetInfo constructor, only to override
it in the NVPTX{32,64}TargetInfo constructors. It worked well enough on
Linux and Mac, but Windows is LLP64, which is different enough to break
it.
This patch removes the NVPTX{32,64}TargetInfo classes entirely and fixes
the bug described above.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28322
llvm-svn: 291135
Summary: CUDA attributes are spelled __declspec(__foo__) on Windows.
Reviewers: tra
Subscribers: cfe-commits, rnk
Differential Revision: https://reviews.llvm.org/D28321
llvm-svn: 291134
Summary:
For the most part this is straightforward: Just add a CudaInstallation
object to the MSVC and MinGW toolchains.
CudaToolChain has to override computeMSVCVersion so that
Clang::constructJob passes the right version flag to cc1. We have to
modify IsWindowsMSVC and friends in Clang::constructJob to be true when
compiling CUDA device code on Windows for the same reason.
Depends on: D28319
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28320
llvm-svn: 291131
Summary:
Previously it was taking the true target triple, which is not really
what it needs: The location of the CUDA installation depends on the host
OS.
Reviewers: tra
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28319
llvm-svn: 291130
Summary:
When Sema looks up an attribute name, it strips off leading and trailing
"__" if the attribute is GNU-style. That is, __attribute__((foo)) and
__attribute__((__foo__)) are equivalent.
This is only true for GNU-style attributes. In particular,
__declspec(__foo__) is not equivalent to __declspec(foo), and Sema
respects this difference.
This patch fixes TableGen to match Sema's behavior. The spelling
'GNU<"__foo__">' should be normalized to 'GNU<"foo">', but
'Declspec<"__foo__">' should not be changed.
This is necessary to make CUDA compilation work on Windows, because e.g.
the __device__ attribute is spelled __declspec(__device__).
Attr.td does not contain any Declspec spellings that start or end with
"__", so this change should not affect any other attributes.
Reviewers: rnk
Subscribers: cfe-commits, tra
Differential Revision: https://reviews.llvm.org/D28318
llvm-svn: 291129
Summary:
These duplicate declarations cause a problem for CUDA compiles on
Windows. All implicitly-defined functions are host+device, and this
applies to the declarations in Builtin.def. But then when we see the
declarations in intrin.h, they have no attributes, so are host-only
functions. This is an error.
(A better fix might be to make these builtins host-only, but that is a
much bigger change.)
Reviewers: rnk
Subscribers: cfe-commits, echristo
Differential Revision: https://reviews.llvm.org/D28317
llvm-svn: 291128
Richard Smith