Commit Graph

28403 Commits

Author SHA1 Message Date
Weston Carvalho be5c7c5d82 Widen `name` stencil to support `TypeLoc` nodes.
Differential Revision: https://reviews.llvm.org/D102185
2021-05-13 23:23:12 +01:00
Aakanksha Patil 464e4dc50f [AMDGPU] Add gfx1034 target
Differential Revision: https://reviews.llvm.org/D102306
2021-05-13 14:25:18 -04:00
Artem Dergachev 6a079dfdc9 [ASTMatchers] Add forCallable(), a generalization of forFunction().
The new matcher additionally covers blocks and Objective-C methods.

This matcher actually makes sure that the statement truly belongs
to that declaration's body. forFunction() incorrectly reported that
a statement in a nested block belonged to the surrounding function.

forFunction() is now deprecated due to the above footgun, in favor of
forCallable(functionDecl()) when only functions need to be considered.

Differential Revision: https://reviews.llvm.org/D102213
2021-05-13 11:25:00 -07:00
Artem Dergachev dd98ea528c [ASTMatchers] NFC: Fix formatting around forFunction().
Differential Revision: https://reviews.llvm.org/D102303
2021-05-13 11:25:00 -07:00
cynecx 8ec9fd4839 Support unwinding from inline assembly
I've taken the following steps to add unwinding support from inline assembly:

1) Add a new `unwind` "attribute" (like `sideeffect`) to the asm syntax:

```
invoke void asm sideeffect unwind "call thrower", "~{dirflag},~{fpsr},~{flags}"()
    to label %exit unwind label %uexit
```

2.) Add Bitcode writing/reading support + LLVM-IR parsing.

3.) Emit EHLabels around inline assembly lowering (SelectionDAGBuilder + GlobalISel) when `InlineAsm::canThrow` is enabled.

4.) Tweak InstCombineCalls/InlineFunction pass to not mark inline assembly "calls" as nounwind.

5.) Add clang support by introducing a new clobber: "unwind", which lower to the `canThrow` being enabled.

6.) Don't allow unwinding callbr.

Reviewed By: Amanieu

Differential Revision: https://reviews.llvm.org/D95745
2021-05-13 19:13:03 +01:00
Duncan P. N. Exon Smith 23e9146fba Modules: Rename ModuleBuildFailed => DisableGeneratingGlobalModuleIndex, NFC
Rename CompilerInstance's ModuleBuildFailed field to
DisableGeneratingGlobalModuleIndex, which more precisely describes its
role. Otherwise, it's hard to suss out how it's different from
ModuleLoader::HadFatalFailure, and what sort of code simplifications are
safe.

Differential Revision: https://reviews.llvm.org/D101670
2021-05-13 10:22:40 -07:00
Duncan P. N. Exon Smith 7c2afd5899 Modules: Remove ModuleLoader::OtherUncachedFailure, NFC
5cca622310 refactored
CompilerInstance::loadModule, splitting out
findOrCompileModuleAndReadAST, but was careful to avoid making any
functional changes. It added ModuleLoader::OtherUncachedFailure to
facilitate this and left behind FIXMEs asking why certain failures
weren't cached.

After a closer look, I think we can just remove this and simplify the
code. This changes the behaviour of the following (simplified) code from
CompilerInstance::loadModule, causing a failure to be cached more often:

```
  if (auto MaybeModule = MM.getCachedModuleLoad(*Path[0].first))
    return *MaybeModule;
  if (ModuleName == getLangOpts().CurrentModule)
    return MM.cacheModuleLoad(PP.lookupModule(...));
  ModuleLoadResult Result = findOrCompileModuleAndReadAST(...);
  if (Result.isNormal()) // This will be 'true' more often.
    return MM.cacheModuleLoad(..., Module);
  return Result;
```

`MM` here is a ModuleMap owned by the Preprocessor. Here are the cases
where `findOrCompileModuleAndReadAST` starts returning a "normal" failed
result:
- Emitted `diag::err_module_not_found`, where there's no module map
  found.
- Emitted `diag::err_module_build_disabled`, where implicitly building
  modules is disabled.
- Emitted `diag::err_module_cycle`, which detects module cycles in the
  implicit modules build system.
- Emitted `diag::err_module_not_built`, which avoids building a module
  in this CompilerInstance if another one tried and failed already.
- `compileModuleAndReadAST()` was called and failed to build.

The four errors are all fatal, and last item also reports a fatal error,
so it this extra caching has no functionality change... but even if it
did, it seems fine to cache these failed results within a ModuleMap
instance (note that each CompilerInstance has its own Preprocessor and
ModuleMap).

Differential Revision: https://reviews.llvm.org/D101667
2021-05-13 10:10:46 -07:00
Lei Huang 9469ff15b7 [PowerPC] Add clang option -m[no-]prefixed
Add user-facing front end option to turn off power10 prefixed instructions.

Reviewed By: nemanjai

Differential Revision: https://reviews.llvm.org/D102191
2021-05-13 12:02:10 -05:00
Aaron En Ye Shi 6a67e05a26 [HIP] Add __builtin_amdgcn_groupstaticsize
Differential Revision: https://reviews.llvm.org/D102403
2021-05-13 15:50:08 +00:00
Zarko Todorovski 8fa168fc50 Parse vector bool when stdbool.h and altivec.h are included
Currently when including stdbool.h and altivec.h declaration of `vector bool` leads to
errors due to `bool` being expanded to '_Bool`. This patch allows the parser
to recognize `_Bool`.

Reviewed By: hubert.reinterpretcast, Everybody0523

Differential Revision: https://reviews.llvm.org/D102064
2021-05-13 11:48:32 -04:00
Vassil Vassilev 92f9852fc9 [clang-repl] Recommit "Land initial infrastructure for incremental parsing"
Original commit message:

  In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
  mentioned our plans to make some of the incremental compilation facilities
  available in llvm mainline.

  This patch proposes a minimal version of a repl, clang-repl, which enables
  interpreter-like interaction for C++. For instance:

  ./bin/clang-repl
  clang-repl> int i = 42;
  clang-repl> extern "C" int printf(const char*,...);
  clang-repl> auto r1 = printf("i=%d\n", i);
  i=42
  clang-repl> quit

  The patch allows very limited functionality, for example, it crashes on invalid
  C++. The design of the proposed patch follows closely the design of cling. The
  idea is to gather feedback and gradually evolve both clang-repl and cling to
  what the community agrees upon.

  The IncrementalParser class is responsible for driving the clang parser and
  codegen and allows the compiler infrastructure to process more than one input.
  Every input adds to the “ever-growing” translation unit. That model is enabled
  by an IncrementalAction which prevents teardown when HandleTranslationUnit.

  The IncrementalExecutor class hides some of the underlying implementation
  details of the concrete JIT infrastructure. It exposes the minimal set of
  functionality required by our incremental compiler/interpreter.

  The Transaction class keeps track of the AST and the LLVM IR for each
  incremental input. That tracking information will be later used to implement
  error recovery.

  The Interpreter class orchestrates the IncrementalParser and the
  IncrementalExecutor to model interpreter-like behavior. It provides the public
  API which can be used (in future) when using the interpreter library.

  Differential revision: https://reviews.llvm.org/D96033
2021-05-13 06:30:29 +00:00
Vassil Vassilev f6907152db Revert "[clang-repl] Land initial infrastructure for incremental parsing"
This reverts commit 44a4000181.

We are seeing build failures due to missing dependency to libSupport and
CMake Error at tools/clang/tools/clang-repl/cmake_install.cmake
file INSTALL cannot find
2021-05-13 04:44:19 +00:00
Vassil Vassilev 44a4000181 [clang-repl] Land initial infrastructure for incremental parsing
In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.

This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:

./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit

The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.

The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.

The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.

The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.

The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.

Differential revision: https://reviews.llvm.org/D96033
2021-05-13 04:23:24 +00:00
Richard Smith e1aa528d3a Handle unexpanded packs appearing in type-constraints.
For a type-constraint in a lambda signature, this makes the lambda
contain an unexpanded pack; for requirements in a requires-expressions
it makes the requires-expression contain an unexpanded pack; otherwise
it's invalid.
2021-05-12 18:45:34 -07:00
Richard Smith 5bb7e81c64 Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope.
This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

Differential Revision: https://reviews.llvm.org/D101968
2021-05-12 13:13:21 -07:00
Erich Keane 08ba9ce1ef Suppress Deferred Diagnostics in discarded statements.
It doesn't really make sense to emit language specific diagnostics
in a discarded statement, and suppressing these diagnostics results in a
programming pattern that many users will feel is quite useful.

Basically, this makes sure we only emit errors from the 'true' side of a
'constexpr if'.

It does this by making the ExprEvaluatorBase type have an opt-in option
as to whether it should visit discarded cases.

Differential Revision: https://reviews.llvm.org/D102251
2021-05-12 12:48:47 -07:00
Pratyush Das 99d63ccff0 Add type information to integral template argument if required.
Non-comprehensive list of cases:
 * Dumping template arguments;
 * Corresponding parameter contains a deduced type;
 * Template arguments are for a DeclRefExpr that hadMultipleCandidates()

Type information is added in the form of prefixes (u8, u, U, L),
suffixes (U, L, UL, LL, ULL) or explicit casts to printed integral template
argument, if MSVC codeview mode is disabled.

Differential revision: https://reviews.llvm.org/D77598
2021-05-12 19:00:08 +00:00
Benjamin Kramer 1470b8587f Remove AST inclusion from Basic include
That's a cyclic dependency. NFC.
2021-05-12 19:51:21 +02:00
Roman Lebedev 81f56a2eb3
[NFC][clang][Codegen] Split ThunkInfo into it's own header
Otherwise we'll have issues with forward definition of GlobalDecl.

Split off from https://reviews.llvm.org/D100388
2021-05-12 20:39:54 +03:00
Yaxun (Sam) Liu 98575708da [CUDA][HIP] Fix device template variables
Currently clang does not emit device template variables
instantiated only in host functions, however, nvcc is
able to do that:

https://godbolt.org/z/fneEfferY

This patch fixes this issue by refactoring and extending
the existing mechanism for emitting static device
var ODR-used by host only. Basically clang records
device variables ODR-used by host code and force
them to be emitted in device compilation. The existing
mechanism makes sure these device variables ODR-used
by host code are added to llvm.compiler-used, therefore
they are guaranteed not to be deleted.

It also fixes non-ODR-use of static device variable by host code
causing static device variable to be emitted and registered,
which should not.

Reviewed by: Artem Belevich

Differential Revision: https://reviews.llvm.org/D102237
2021-05-12 11:13:29 -04:00
Richard Smith bb726383ac Revert "Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope."
This reverts commit 697ac15a0f, for which
review was not complete. That change was accidentally pushed when
an unrelated change was pushed.
2021-05-11 17:46:18 -07:00
Richard Smith 697ac15a0f Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope.
This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

Differential Revision: https://reviews.llvm.org/D101968
2021-05-11 17:35:33 -07:00
Victor Huang 46475a79f8 [AIX][TLS] Diagnose use of unimplemented TLS models
Add front end diagnostics to report error for unimplemented TLS models set by
- compiler option `-ftls-model`
- attributes like `__thread int __attribute__((tls_model("local-exec"))) var_name;`

Reviewed by: aaron.ballman, nemanjai, PowerPC

Differential Revision: https://reviews.llvm.org/D102070
2021-05-11 17:21:08 -05:00
Anastasia Stulova 13ea238b1e [OpenCL] Allow use of double type without extension pragma.
Simply use of extensions by allowing the use of supported
double types without the pragma. Since earlier standards
instructed that the pragma is used explicitly a new warning
is introduced in pedantic mode to indicate that use of
type without extension pragma enable can be non-portable.

This patch does not break backward compatibility since the
extension pragma is still supported and it makes the behavior
of the compiler less strict by accepting code without extra
pragma statements.

Differential Revision: https://reviews.llvm.org/D100980
2021-05-11 12:54:38 +01:00
Craig Topper 18f3a14e13 [RISCV] Validate the SEW and LMUL operands to __builtin_rvv_vsetvli(max)
These are required to be constants, this patch makes sure they
are in the accepted range of values.

These are usually created by wrappers in the riscv_vector.h header
which should always be correct. This patch protects against a user
using the builtin directly.

Reviewed By: khchen

Differential Revision: https://reviews.llvm.org/D102086
2021-05-10 12:11:13 -07:00
Xiang1 Zhang d4bdeca576 [X86] Support AMX fast register allocation
Differential Revision: https://reviews.llvm.org/D100026
2021-05-08 14:21:11 +08:00
Xiang1 Zhang bebafe01a7 Revert "[X86] Support AMX fast register allocation"
This reverts commit 77e2e5e07d.
2021-05-08 13:43:32 +08:00
Xiang1 Zhang 77e2e5e07d [X86] Support AMX fast register allocation 2021-05-08 13:27:21 +08:00
Weston Carvalho 1f65f42dd3 Make `hasTypeLoc` matcher support more node types.
Differential Revision: https://reviews.llvm.org/D101572
2021-05-08 00:35:22 +01:00
Weston Carvalho 0ad494838b NFC: Move TypeList implementation up the file
This will make it possible for more code to use it.
2021-05-08 00:35:13 +01:00
Ahsan Saghir 25bbff632d [PowerPC] Provide MMA builtins for compatibility
Vector pair intrinsics and builtins were renamed in
https://reviews.llvm.org/D91974 to replace the _mma_ prefix by _vsx_.
However, some projects used the _mma_ version, so this patch adds
these intrinsics to provide compatibility.

Fixes Bugzilla: https://bugs.llvm.org/show_bug.cgi?id=50159

Reviewed By: nemanjai, amyk

Differential Revision: https://reviews.llvm.org/D100482
2021-05-07 09:10:16 -05:00
Anastasia Stulova 76f1de10f4 [OpenCL] Fix optional image types.
This change allows the use of identifiers for image types
from `cl_khr_gl_msaa_sharing` freely in the kernel code if
the extension is not supported since they are not in the
list of the reserved identifiers.

This change also removed the need for pragma for the types
in the extensions since the spec does not require the pragma
uses.

Differential Revision: https://reviews.llvm.org/D100983
2021-05-07 13:29:28 +01:00
Stanislav Mekhanoshin c714d03785 [AMDGPU] Expose __builtin_amdgcn_perm for v_perm_b32
Differential Revision: https://reviews.llvm.org/D102022
2021-05-06 16:17:33 -07:00
Paul C. Anagnostopoulos d40a0b8af7 [TableGen] [Clang] Clean up Options.td and add asserts.
Differential Revision: https://reviews.llvm.org/D101766
2021-05-06 09:32:25 -04:00
Johannes Doerfert df729e2b82 [OpenMP] Overhaul `declare target` handling
This patch fixes various issues with our prior `declare target` handling
and extends it to support `omp begin declare target` as well.

This started with PR49649 in mind, trying to provide a way for users to
avoid the "ref" global use introduced for globals with internal linkage.
From there it went down the rabbit hole, e.g., all variables, even
`nohost` ones, were emitted into the device code so it was impossible to
determine if "ref" was needed late in the game (based on the name only).
To make it really useful, `begin declare target` was needed as it can
carry the `device_type`. Not emitting variables eagerly had a ripple
effect. Finally, the precedence of the (explicit) declare target list
items needed to be taken into account, that meant we cannot just look
for any declare target attribute to make a decision. This caused the
handling of functions to require fixup as well.

I tried to clean up things while I was at it, e.g., we should not "parse
declarations and defintions" as part of OpenMP parsing, this will always
break at some point. Instead, we keep track what region we are in and
act on definitions and declarations instead, this is what we do for
declare variant and other begin/end directives already.

Highlights:
  - new diagnosis for restrictions specificed in the standard,
  - delayed emission of globals not mentioned in an explicit
    list of a declare target,
  - omission of `nohost` globals on the host and `host` globals on the
    device,
  - no explicit parsing of declarations in-between `omp [begin] declare
    variant` and the corresponding end anymore, regular parsing instead,
  - precedence for explicit mentions in `declare target` lists over
    implicit mentions in the declaration-definition-seq, and
  - `omp allocate` declarations will now replace an earlier emitted
    global, if necessary.

---

Notes:

The patch is larger than I hoped but it turns out that most changes do
on their own lead to "inconsistent states", which seem less desirable
overall.

After working through this I feel the standard should remove the
explicit declare target forms as the delayed emission is horrible.
That said, while we delay things anyway, it seems to me we check too
often for the current status even though that is often not sufficient to
act upon. There seems to be a lot of duplication that can probably be
trimmed down. Eagerly emitting some things seems pretty weak as an
argument to keep so much logic around.

---

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D101030
2021-05-06 02:10:41 -05:00
Thomas Lively 602f318cfd [WebAssembly] Fix constness of pointer params to load intrinsics
Update the SIMD builtin load functions to take pointers to const data and update
the intrinsics themselves to not cast away constness.

Differential Revision: https://reviews.llvm.org/D101884
2021-05-05 13:16:56 -07:00
Thomas Lively 627a526955 [WebAssembly] Update narrowing builtin function operand types
Make the inputs to all narrowing builtins signed, which is how they are
interpreted by the underlying instructions (only the result changes sign
between instructions).

Differential Revision: https://reviews.llvm.org/D101883
2021-05-05 13:04:04 -07:00
Nick Desaulniers aefbfbcbd7 [Clang] remove text extension from diag::err_drv_invalid_value_with_suggestion
This hinders translations, as per:
https://clang.llvm.org/docs/InternalsManual.html#the-format-string

Reviewed By: MaskRay, xbolva00

Differential Revision: https://reviews.llvm.org/D101387
2021-05-05 11:01:43 -07:00
Anastasia Stulova e994e74bca [OpenCL] Add clang extension for non-portable kernel parameters.
Added __cl_clang_non_portable_kernel_param_types extension that
allows using non-portable types as kernel parameters. This allows
bypassing the portability guarantees from the restrictions specified
in C++ for OpenCL v1.0 s2.4.

Currently this only disables the restrictions related to the data
layout. The programmer should ensure the compiler generates the same
layout for host and device or otherwise the argument should only be
accessed on the device side. This extension could be extended to other
case (e.g. permitting size_t) if desired in the future.

Patch by olestrohm (Ole Strohm)!

https://reviews.llvm.org/D101168
2021-05-05 14:58:23 +01:00
Yang Fan cab3c6c6c4
[clang][TargetCXXABI] Fix -Wreturn-type warning (NFC)
GCC warning:
```
In file included from /llvm-project/clang/include/clang/Basic/LangOptions.h:22,
                 from /llvm-project/clang/include/clang/Frontend/CompilerInvocation.h:16,
                 from /llvm-project/clang/lib/Frontend/CompilerInvocation.cpp:9:
/llvm-project/clang/include/clang/Basic/TargetCXXABI.h: In static member function ‘static bool clang::TargetCXXABI::isSupportedCXXABI(const llvm::Triple&, clang::TargetCXXABI::Kind)’:
/llvm-project/clang/include/clang/Basic/TargetCXXABI.h:114:3: warning: control reaches end of non-void function [-Wreturn-type]
  114 |   };
      |   ^
```
2021-05-05 14:44:48 +08:00
Adrian Prantl 6c3a10760d Mark Basic/TargetCXXABI.def as textual in the module map. 2021-05-04 12:52:52 -07:00
Leonard Chan 84c4754372 [clang] Add -fc++-abi= flag for specifying which C++ ABI to use
This implements the flag proposed in RFC
http://lists.llvm.org/pipermail/cfe-dev/2020-August/066437.html.

The goal is to add a way to override the default target C++ ABI through a
compiler flag. This makes it easier to test and transition between different
C++ ABIs through compile flags rather than build flags.

In this patch:

- Store -fc++-abi= in a LangOpt. This isn't stored in a CodeGenOpt because
  there are instances outside of codegen where Clang needs to know what the
  ABI is (particularly through ASTContext::createCXXABI), and we should be
  able to override the target default if the flag is provided at that point.
- Expose the existing ABIs in TargetCXXABI as values that can be passed
  through this flag.
  - Create a .def file for these ABIs to make it easier to check flag values.
  - Add an error for diagnosing bad ABI flag values.

Differential Revision: https://reviews.llvm.org/D85802
2021-05-04 10:52:13 -07:00
Zachary Henkel 54bff1522f Rename a template parameter that conflicted with a common macro; NFC
The CALLBACK macro is used extensively in the Windows SDK.
2021-05-04 11:19:54 -04:00
Ella Ma d882750f11 [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.
The first crash reported in the bug report 44338.

Condition `!isSat.hasValue() || isNotSat.getValue()` here should be
`!isNotSat.hasValue() || isNotSat.getValue()`.
`getValue()` here crashed when we used the static analyzer to analyze
postgresql-12.0.

Patch By: OikawaKirie

Reviewed By: steakhal, martong

Differential Revision: https://reviews.llvm.org/D83660
2021-05-04 16:50:21 +02:00
Nico Weber d7ec48d71b [clang] accept -fsanitize-ignorelist= in addition to -fsanitize-blacklist=
Use that for internal names (including the default ignorelists of the
sanitizers).

Differential Revision: https://reviews.llvm.org/D101832
2021-05-04 10:24:00 -04:00
Jan Svoboda 00895831ab [clang][cli][docs] Clarify marshalling infrastructure documentation 2021-05-04 15:16:32 +02:00
Jan Svoboda d0e3a15e36 [clang][cli] NFC: Remove confusing `EmptyKPM` variable 2021-05-04 14:27:57 +02:00
serge-sans-paille b83b23275b Introduce -Wreserved-identifier
Warn when a declaration uses an identifier that doesn't obey the reserved
identifier rule from C and/or C++.

Differential Revision: https://reviews.llvm.org/D93095
2021-05-04 11:19:01 +02:00
Marek Kurdej 8d93d7ffed [clang-format] Add options to AllowShortIfStatementsOnASingleLine to apply to "else if" and "else".
This fixes the bug http://llvm.org/pr50019.

Reviewed By: MyDeveloperDay

Differential Revision: https://reviews.llvm.org/D100727
2021-05-03 18:11:25 +02:00
Nathan Sidwell ab7316f1c6 [clang] Spell correct variable
fix Trailling -> Trailing (two ll-> one l)

Differential Revision: https://reviews.llvm.org/D101753
2021-05-03 05:33:47 -07:00