| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
pragma
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
 | 
| | 
| 
| 
|  | 
llvm-svn: 291528
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
ConstantEvaluated when parsing a constant expression.
This renaming makes it consistent with the context it actually sets: Sema::ConstantEvaluated.
llvm-svn: 291525
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: rsmith, EricWF
Subscribers: mehdi_amini, llvm-commits, EricWF
Differential Revision: https://reviews.llvm.org/D26038
llvm-svn: 291513
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
Forgot to add this file as a part of r291418.
llvm-svn: 291493
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
version.
Differential Revision: https://reviews.llvm.org/D28418
llvm-svn: 291491
 | 
| | 
| 
| 
| 
| 
|  | 
in C++. Follow suit.
llvm-svn: 291489
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
test/CodeGenCXX/dllexport.cpp has grown quite large at this point. NFC
llvm-svn: 291452
 | 
| | 
| 
| 
| 
| 
| 
|  | 
This pointer comparison has shown to be error-prone, so use the standard
helper for it. NFC
llvm-svn: 291450
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
on constexpr lambdas from appearing within function-signatures (CWG1607)
For further background, see Richard's comments: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170109/181998.html
A patch to fix this is being worked on.
Thanks!
llvm-svn: 291439
 | 
| | 
| 
| 
| 
| 
|  | 
covering polys.
llvm-svn: 291437
 | 
| | 
| 
| 
|  | 
llvm-svn: 291436
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Before:
  bool a = f() &&override.f();
  bool a = f() &&final.f();
  void f(const MyOverride & override);
  void f(const MyFinal & final);
After:
  bool a = f() && override.f();
  bool a = f() && final.f();
  void f(const MyOverride &override);
  void f(const MyFinal &final);
llvm-svn: 291434
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Patch by: Adam Balogh!
Differential Revision: https://reviews.llvm.org/D25660
llvm-svn: 291430
 | 
| | 
| 
| 
|  | 
llvm-svn: 291429
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Bots seem happy with `diagnose_if` so far, so I'm optimistically adding
release notes for it.
llvm-svn: 291422
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
`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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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.
llvm-svn: 291416
 | 
| | 
| 
| 
| 
| 
|  | 
The test-suite bots are still failing even after r291410's fix.
llvm-svn: 291412
 | 
| | 
| 
| 
| 
| 
|  | 
long', not 'long'.
llvm-svn: 291411
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
|  | 
Initially reports if a constructor symbol is a copy or move constructor.
llvm-svn: 291409
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This fixes ObjC exceptions on Win64 (which uses SEH), among others.
Patch by Jonathan Schleifer!
llvm-svn: 291408
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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.
llvm-svn: 291403
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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).
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 should allow clang to successfully compile libstdc++4.8's headers in C++14
mode.
llvm-svn: 291382
 | 
| | 
| 
| 
|  | 
llvm-svn: 291360
 | 
| | 
| 
| 
| 
| 
|  | 
except for those with the "attributes are unevaluated contexts" flag.
llvm-svn: 291358
 | 
| | 
| 
| 
|  | 
llvm-svn: 291319
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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).
llvm-svn: 291318
 | 
| | 
| 
| 
| 
| 
|  | 
This should fix bot failures in this test.
llvm-svn: 291310
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
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
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
Summary: This intended as a debugging/development flag only.
Differential Revision: https://reviews.llvm.org/D28385
llvm-svn: 291300
 |