Textual headers and builtins that are #import'd from different
modules should get re-entered when these modules are independent
from each other.
Differential Revision: https://reviews.llvm.org/D26267
rdar://problem/25881934
llvm-svn: 291644
Fix a crash in body farm when synthesizing a getter for a property
synthesized for a property declared in a protocol on a class extension
that shadows a declaration of the property in a category.
In this case, Sema doesn't fill in the implicit 'self' parameter for the getter
in the category, which leads to a crash when trying to synthesize the getter
for it.
To avoid the crash, skip getter synthesis in body farm if the self parameter is
not filled int.
rdar://problem/29938138
llvm-svn: 291635
Summary:
openSuse has AArch64 support, with images running on the Raspberry Pi 3.
The libraries and headers live under the aarch64-suse-linux subdirectory,
which is currently not in the AArch64 triples list. Address this by adding
the corresponding string to AArch64Triples.
Reviewers: chandlerc, bruno, bkramer, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D28238
llvm-svn: 291598
Sema treats pointers to static member functions as having function pointer
type, so treat treat them as function pointer values in the analyzer as well.
This prevents an assertion failure in SValBuilder::evalBinOp caused by code
that expects function pointers to be Locs (in contrast, PointerToMember values
are nonlocs).
Differential Revision: https://reviews.llvm.org/D28033
llvm-svn: 291581
This patch is to implement sema and parsing for 'target teams distribute simd’ pragma.
Differential Revision: https://reviews.llvm.org/D28252
llvm-svn: 291579
Summary:
This patch introduces support for the execution of parallel constructs in a target
region on the NVPTX device. Parallel regions must be in the lexical scope of the
target directive.
The master thread in the master warp signals parallel work for worker threads in worker
warps on encountering a parallel region.
Note: The patch does not yet support capture of arguments in a parallel region so
the test cases are simple.
Reviewers: ABataev
Differential Revision: https://reviews.llvm.org/D28145
llvm-svn: 291565
This commit ensures that clang avoids the redundant -Wshadow warning for
variables that already get a "redefinition of " error.
rdar://29067894
Differential Revision: https://reviews.llvm.org/D28350
llvm-svn: 291564
Don't prematurely clean up an RAII object; there's another RAII object in the
same scope that tries to save and restore the same member!
llvm-svn: 291551
Summary:
This patch enables the following
1. AMD family 17h architecture using "znver1" tune flag (-march, -mcpu).
2. ISAs that are enabled for "znver1" architecture.
3. Checks ADX isa from cpuid to identify "znver1" flag when -march=native is used.
4. ISAs FMA4, XOP are disabled as they are dropped from amdfam17.
5. For the time being, it uses the btver2 scheduler model.
6. Test file is updated to check this flag.
This is linked to llvm review item https://reviews.llvm.org/D28017
Patch by Ganesh Gopalasubramanian. Additional test cases added by Craig Topper.
Reviewers: RKSimon, craig.topper
Subscribers: cfe-commits, RKSimon, ashutosh.nema, llvm-commits
Differential Revision: https://reviews.llvm.org/D28018
llvm-svn: 291544
This patch is to add support of the 'is_device_ptr' clause with the 'target parallel for' pragma.
Differential Revision: https://reviews.llvm.org/D28255
llvm-svn: 291540
This patch is to add support of the 'is_device_ptr' clause with the 'target parallel for simd' pragma.
Differential Revision: https://reviews.llvm.org/D28402
llvm-svn: 291537
properly even when a non-type template parameter has a dependent type.
Previously, if a non-type template parameter was dependent, but not dependent
on an outer level of template parameter, we would not match the type of the
parameter. Under [temp.arg.template], we are supposed to check that the types
are equivalent, which means checking for syntactic equivalence in the dependent
case.
This also fixes some accepts-invalids when passing templates with auto-typed
non-type template parameters as template template arguments.
llvm-svn: 291512
Use the new --cmakedir option to obtain LLVM_CMAKE_PATH straight from
llvm-config instead of reconstructing it locally.
Differential Revision: https://reviews.llvm.org/D26900
llvm-svn: 291495
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.
llvm-svn: 291484
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.)
Reviewers: rsmith
Subscribers: EricWF, cfe-commits
Differential Revision: https://reviews.llvm.org/D28427
llvm-svn: 291480
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.
Differential Revision: https://reviews.llvm.org/D28213
llvm-svn: 291477
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.
Differential Revision: http://reviews.llvm.org/D28415
llvm-svn: 291465
In C++11, a destructor's implicit exception-spec is nothrow.
The IR for the destructor's invocation changed from invoke to call.
Differential Revision: https://reviews.llvm.org/D28425
llvm-svn: 291458
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.
llvm-svn: 291453
This diffs enables using --section-ordering-file option of ld.gold
via the variable CLANG_ORDER_FILE.
Differential revision: https://reviews.llvm.org/D28461
llvm-svn: 291449
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".
llvm-svn: 291448
Summary:
Automatic semicolon insertion should break import and export statements:
Before, this would format on one line:
// Note: no semi after 'x' below!
import {x} from 'x'
export function foo() {}
Into:
import {x} from 'x' export function foo() {}
With this change, the statements get separated.
This also improves automatic semicolon insertion to consider closing
braces preceding declarations and statements.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28465
llvm-svn: 291428
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.
llvm-svn: 291427
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).
llvm-svn: 291425
`diagnose_if` can be used to have clang emit either warnings or errors
for function calls that meet user-specified conditions. For example:
```
constexpr int foo(int a)
__attribute__((diagnose_if(a > 10, "configurations with a > 10 are "
"expensive.", "warning")));
int f1 = foo(9);
int f2 = foo(10); // warning: configuration with a > 10 are expensive.
int f3 = foo(f2);
```
It currently only emits diagnostics in cases where the condition is
guaranteed to always be true. So, the following code will emit no
warnings:
```
constexpr int bar(int a) {
foo(a);
return 0;
}
constexpr int i = bar(10);
```
We hope to support optionally emitting diagnostics for cases like that
(and emitting runtime checks) in the future.
Release notes will appear shortly. :)
Differential Revision: https://reviews.llvm.org/D27424
llvm-svn: 291418
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.
llvm-svn: 291416
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.
llvm-svn: 291410
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.)
llvm-svn: 291407
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.
llvm-svn: 291403
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).
Thanks!
llvm-svn: 291397
I originally requested this to be tested in D25263 but in the end
forgot to make sure that it was done.
Differential Revision: https://reviews.llvm.org/D28289
llvm-svn: 291389
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
Bruno Cardoso Lopes