Richard Smith [Mon, 9 Jan 2017 21:40:40 +0000 (21:40 +0000)]
PR31587: Fix handling of __FUNCSIG__ in C.
Fix crash if __FUNCSIG__ is used in a function without a prototype, and use
"(void)" as parameter list instead of "()" for a function with a no-parameters
prototype, matching MSVC's observed behavior.
David L. Jones [Mon, 9 Jan 2017 21:38:07 +0000 (21:38 +0000)]
Allow constexpr construction of subobjects unconditionally, not just in C++14.
Summary:
Per https://wg21.link/CWG1677, the C++11 standard did not clarify that constant
initialization of an object allowed constexpr brace-or-equal initialization of
subobjects:
struct foo_t { union { int i; volatile int j; } u; };
__attribute__((__require_constant_initialization__))
static const foo_t x = {{0}};
Because foo_t::u has a volatile member, the initializer for x fails. However,
there is really no good reason, because this:
union foo_u { int i; volatile int j; };
__attribute__((__require_constant_initialization__))
static const foo_u x = {0};
does have a constant initializer.
(This was triggered by musl's pthread_mutex_t type when building under C++11.)
Michal Gorny [Mon, 9 Jan 2017 20:54:20 +0000 (20:54 +0000)]
[Frontend] Correct values of ATOMIC_*_LOCK_FREE to match builtin
Correct the logic used to set ATOMIC_*_LOCK_FREE preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for _Atomic types even if the underlying types are aligned to a lower
boundary by default.
For example, the 'long long' and 'double' types on x86 are aligned to
32-bit boundary by default. However, '_Atomic long long' and '_Atomic
double' are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.
This fixes PR #19355 by correcting the value of
__GCC_ATOMIC_LLONG_LOCK_FREE on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.
Manman Ren [Mon, 9 Jan 2017 19:20:18 +0000 (19:20 +0000)]
PCH: fix a regression that reports a module is defined in both pch and pcm.
In r276159, we started to say that a module X is defined in a pch if we specify
-fmodule-name when building the pch. This caused a regression that reports
module X is defined in both pch and pcm if we generate the pch with
-fmodule-name=X and then in a separate clang invocation, we include the pch and
also import X.pcm.
This patch adds an option CompilingPCH similar to CompilingModule. When we use
-fmodule-name=X while building a pch, modular headers in X will be textually
included and the compiler knows that we are not building module X, so we don't
put module X in SUBMODULE_DEFINITION of the pch.
Reid Kleckner [Mon, 9 Jan 2017 17:27:17 +0000 (17:27 +0000)]
[MS] Mark default args of exported default constructors as used
Fixes a regression introduced in r291045, which would lead to link
errors. While we should no longer encounter unparsed or uninstantiated
default arguments in this codepath, we still need to call
CheckCXXDefaultArgExpr to mark the default argument expressions as
ODR-used.
Reid Kleckner [Mon, 9 Jan 2017 17:04:37 +0000 (17:04 +0000)]
[MS] Fix function type mangling of default ctor closures
Use the canonical decl in pointer comparisons with the default
constructor closure decl. Otherwise we don't produce the correct
"@@QAEXXZ" mangling, which essentially means "void(void) thiscall public
instance method".
Richard Smith [Mon, 9 Jan 2017 08:01:21 +0000 (08:01 +0000)]
Implement C++ DR1391 (wg21.link/cwg1391)
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811 and r291412, with a couple of
fixes for handling of explicitly-specified non-trailing template argument
packs.
Richard Smith [Mon, 9 Jan 2017 07:14:40 +0000 (07:14 +0000)]
Implement DR1388 (wg21.link/cwg1388).
This issue clarifies how deduction proceeds past a non-trailing function
parameter pack. Essentially, the pack itself is skipped and consumes no
arguments (except for those implied by an explicitly-specified template
arguments), and nothing is deduced from it. As a small fix to the standard's
rule, we do not allow subsequent deduction to change the length of the function
parameter pack (by preventing extension of the explicitly-specified pack if
present, and otherwise deducing all contained packs to empty packs).
Faisal Vali [Mon, 9 Jan 2017 03:02:53 +0000 (03:02 +0000)]
[cxx1z-constexpr-lambda] Implement constant evaluation of non-capturing lambda expressions.
Add a visitor for lambda expressions to RecordExprEvaluator in ExprConstant.cpp that creates an empty APValue of Struct type to represent the closure object. Additionally, add a LambdaExpr visitor to the TemporaryExprEvaluator that forwards constant evaluation of immediately-called-lambda-expressions to the one in RecordExprEvaluator through VisitConstructExpr.
This patch supports:
constexpr auto ID = [] (auto a) { return a; };
static_assert(ID(3.14) == 3.14);
static_assert([](auto a) { return a + 1; }(10) == 11);
Lambda captures are still not supported for constexpr lambdas.
Richard Smith [Mon, 9 Jan 2017 00:43:47 +0000 (00:43 +0000)]
Implement C++ DR1391 (wg21.link/cwg1391)
Check for implicit conversion sequences for non-dependent function
template parameters between deduction and substitution. The idea is to accept
as many cases as possible, on the basis that substitution failure outside the
immediate context is much more common during substitution than during implicit
conversion sequence formation.
This re-commits r290808, reverted in r290811, with a fix for handling of
explicitly-specified template argument packs.
Richard Smith [Sun, 8 Jan 2017 22:45:21 +0000 (22:45 +0000)]
PR31514: Add recursive self-instantiation check during template argument
deduction in partial ordering.
This prevents us from crashing due to attempting to instantiate the same class
template specialization definition multiple times. (Debug builds also appear to
sometimes hit the stack limit before hitting the instantiation depth limit in
this case.)
Richard Smith [Sun, 8 Jan 2017 21:45:44 +0000 (21:45 +0000)]
PR30305: Implement proposed DR resolution to prevent slicing via inherited constructor.
The rule we use is that a construction of a class type T from an argument of
type U cannot use an inherited constructor if U is the same as T or is derived
from T (or if the initialization would first convert it to such a type). This
(approximately) matches the rule in use by GCC, and matches the current proposed
DR resolution.
Faisal Vali [Sun, 8 Jan 2017 18:56:11 +0000 (18:56 +0000)]
[cxx1z-constexpr-lambda] Make conversion function constexpr, and teach the expression-evaluator to evaluate the static-invoker.
This patch has been sitting in review hell since july 2016 and our lack of constexpr lambda support is getting embarrassing (given that I've had a branch that implements the feature (modulo *this capture) for over a year. While in Issaquah I was enjoying shamelessly trying to convince folks of the lie that this was Richard's fault ;) I won't be able to do so in Kona since I won't be attending - so I'm going to aim to have this feature be implemented by then.
I'm quite confident of the approach in this patch, which simply maps the static-invoker 'thunk' back to the corresponding call-operator (specialization).
Richard Smith [Sat, 7 Jan 2017 00:48:55 +0000 (00:48 +0000)]
PR23135: Don't instantiate constexpr functions referenced in unevaluated operands where possible.
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).
Teresa Johnson [Fri, 6 Jan 2017 23:37:33 +0000 (23:37 +0000)]
[ThinLTO] Optionally ignore empty index file
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.
Richard Smith [Fri, 6 Jan 2017 22:52:53 +0000 (22:52 +0000)]
Revisit PR10177: don't instantiate a variable if it's only referenced in a
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.
David Blaikie [Fri, 6 Jan 2017 19:49:01 +0000 (19:49 +0000)]
Reapply "IntrusiveRefCntPtr -> std::shared_ptr for CompilerInvocationBase and CodeCompleteConsumer"
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.
Reid Kleckner [Fri, 6 Jan 2017 18:16:03 +0000 (18:16 +0000)]
[CUDA] Add a host target triple to cuda-version-check.cu
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.
Akira Hatanaka [Fri, 6 Jan 2017 17:56:15 +0000 (17:56 +0000)]
Make ASTContext::getDeclAlign return the correct alignment for
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).
[ubsan] Minimize size of data for type_mismatch (Redo of D19667)
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.
Alex Lorenz [Fri, 6 Jan 2017 12:00:44 +0000 (12:00 +0000)]
[CodeCompletion] Block property setters: Use dynamic priority heuristic
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.
CodeGen: address post commit review comments for r291123
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.
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.
Justin Lebar [Thu, 5 Jan 2017 16:53:38 +0000 (16:53 +0000)]
[CUDA] Let NVPTX inherit the host's calling conventions.
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.)
Justin Lebar [Thu, 5 Jan 2017 16:53:21 +0000 (16:53 +0000)]
[CUDA] More correctly inherit primitive types from the host during device compilation.
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.
Justin Lebar [Thu, 5 Jan 2017 16:52:29 +0000 (16:52 +0000)]
[Driver] Driver changes to support CUDA compilation on Windows.
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.
Justin Lebar [Thu, 5 Jan 2017 16:52:11 +0000 (16:52 +0000)]
[CUDA] Make CUDAInstallationDetector take the host triple in its constructor.
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.
Justin Lebar [Thu, 5 Jan 2017 16:51:54 +0000 (16:51 +0000)]
[TableGen] Only normalize the spelling of GNU-style attributes.
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.
Justin Lebar [Thu, 5 Jan 2017 16:51:37 +0000 (16:51 +0000)]
[Windows] Remove functions in intrin.h that are defined in Builtin.def.
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.)
Samuel Antao [Thu, 5 Jan 2017 16:02:49 +0000 (16:02 +0000)]
[OpenMP] Add fields for flags in the offload entry descriptor.
Summary:
This patch adds two fields to the offload entry descriptor. One field is meant to signal Ctors/Dtors and `link` global variables, and the other is reserved for runtime library use.
Currently, these fields are only filled with zeros in the current code generation, but that will change when `declare target` is added.
The reason, we are adding these fields now is to make the code generation consistent with the runtime library proposal under review in https://reviews.llvm.org/D14031.
inline assembly may use the `.include` directive to include other
content into the file. Without the integrated assembler, the `-I` group
gets passed to the assembler. Emulate this by collecting the header
search paths and passing them to the IAS.
This patch includes updates for codegen of the target region for the NVPTX
device. It moves initializers from the compiler to the runtime and updates
the worker loop to assume parallel work is retrieved from the runtime. A
subsequent patch will update the codegen to retrieve the parallel work using
calls to the runtime. It includes the removal of the inline attribute
for the worker loop and disabling debug info in it.
This allows codegen for a target directive and serial execution on the
NVPTX device.
Dylan McKay [Thu, 5 Jan 2017 05:20:27 +0000 (05:20 +0000)]
Add AVR target and toolchain to Clang
Summary:
Authored by Senthil Kumar Selvaraj
This patch adds barebones support in Clang for the (experimental) AVR target. It uses the integrated assembler for assembly, and the GNU linker for linking, as lld doesn't know about the target yet.
The DataLayout string is the same as the one in AVRTargetMachine.cpp. The alignment specs look wrong to me, as it's an 8 bit target and all types only need 8 bit alignment. Clang failed with a datalayout mismatch error when I tried to change it, so I left it that way for now.
Richard Smith [Thu, 5 Jan 2017 02:31:32 +0000 (02:31 +0000)]
Fix assertion failure on deduction failure due to too short template argument list.
We were previously incorrectly using TDK_TooFewArguments to report a template
argument list that's too short, but it actually means that the number of
arguments in a top-level function call was insufficient. When diagnosing the
problem, SemaOverload would (rightly) assert that the failure kind didn't make
any sense.
Looks like these functions exist just to prevent bad implicit
conversions. Rather than waiting for the linker to complain about
undefined references to them, we can mark them as deleted.
Reid Kleckner [Thu, 5 Jan 2017 01:08:22 +0000 (01:08 +0000)]
[MS] Instantiate default args during instantiation of exported default ctors
Summary:
Replace some old code that probably pre-dated the change to delay
emission of dllexported code until after the closing brace of the
outermost record type. Only uninstantiated default argument expressions
need to be handled now. It is enough to instantiate default argument
expressions when instantiating dllexported default ctors. This also
fixes some double-diagnostic issues in this area.
Erich Keane [Thu, 5 Jan 2017 00:20:51 +0000 (00:20 +0000)]
Correct Vectorcall Register passing and HVA Behavior
Front end component (back end changes are D27392). The vectorcall
calling convention was broken subtly in two cases. First,
it didn't properly handle homogeneous vector aggregates (HVAs).
Second, the vectorcall specification requires that only the
first 6 parameters be eligible for register assignment.
This patch fixes both issues.
[gtest] The way EXPECT_TEST now works after upgrading gtest triggers an
ODR use. These traits don't have a definition as they're intended to be
used strictly at compile time. Change the tests to use static_assert to
move the entire thing into compile-time.
Richard Smith [Wed, 4 Jan 2017 23:14:16 +0000 (23:14 +0000)]
Bail out if we try to build a DeclRefExpr naming an invalid declaration.
Most code paths would already bail out in this case, but certain paths,
particularly overload resolution and typo correction, would not. Carrying on
with an invalid declaration could in some cases result in crashes due to
downstream code relying on declaration invariants that are not necessarily
met for invalid declarations, and in other cases just resulted in undesirable
follow-on diagnostics.
projects / clang / log