Commit Graph

29800 Commits

Author SHA1 Message Date
Paul Kirth bac6cd5bf8 [misexpect] Re-implement MisExpect Diagnostics
Reimplements MisExpect diagnostics from D66324 to reconstruct its
original checking methodology only using MD_prof branch_weights
metadata.

New checks rely on 2 invariants:

1) For frontend instrumentation, MD_prof branch_weights will always be
   populated before llvm.expect intrinsics are lowered.

2) for IR and sample profiling, llvm.expect intrinsics will always be
   lowered before branch_weights are populated from the IR profiles.

These invariants allow the checking to assume how the existing branch
weights are populated depending on the profiling method used, and emit
the correct diagnostics. If these invariants are ever invalidated, the
MisExpect related checks would need to be updated, potentially by
re-introducing MD_misexpect metadata, and ensuring it always will be
transformed the same way as branch_weights in other optimization passes.

Frontend based profiling is now enabled without using LLVM Args, by
introducing a new CodeGen option, and checking if the -Wmisexpect flag
has been passed on the command line.

Reviewed By: tejohnson

Differential Revision: https://reviews.llvm.org/D115907
2022-04-19 21:23:48 +00:00
Alex Langford c57f03415f [clang][Sema] Add flag to LookupName to force C/ObjC codepath
Motivation: The intent here is for use in Swift.
When building a clang module for swift consumption, swift adds an
extension block to the module for name lookup purposes. Swift calls
this a SwiftLookupTable. One purpose that this serves is to handle
conflicting names between ObjC classes and ObjC protocols. They exist in
different namespaces in ObjC programs, but in Swift they would exist in
the same namespace. Swift handles this by appending a suffix to a
protocol name if it shares a name with a class. For example, if you have
an ObjC class named "Foo" and a protocol with the same name, the
protocol would be renamed to "FooProtocol" when imported into swift.

When constructing the previously mentioned SwiftLookupTable, we use
Sema::LookupName to look up name conflicts for the previous problem.
By this time, the Parser has long finished its job so the call to
LookupName gets nullptr for its Scope (TUScope will be nullptr
by this point). The C/ObjC path does not have this problem because it
only uses the Scope in specific scenarios. The C++ codepath uses the
Scope quite extensively and will fail early on if the Scope it gets is
null. In our very specific case of looking up ObjC classes with a
specific name, we want to force sema::LookupName to take the C/ObjC
codepath even if C++ or ObjC++ is enabled.
2022-04-19 12:57:14 -07:00
Denys Petrov e37726beb2 [analyzer] Implemented RangeSet::Factory::castTo function to perform promotions, truncations and conversions.
Summary: Handle casts for ranges working similarly to APSIntType::apply function but for the whole range set. Support promotions, truncations and conversions.
Example:
promotion: char [0, 42] -> short [0, 42] -> int [0, 42] -> llong [0, 42]
truncation: llong [4295033088, 4295033130] -> int [65792, 65834] -> short [256, 298] -> char [0, 42]
conversion: char [-42, 42] -> uint [0, 42]U[4294967254, 4294967295] -> short[-42, 42]

Differential Revision: https://reviews.llvm.org/D103094
2022-04-19 22:34:03 +03:00
Tom Ritter 82f3ed9904 [analyzer] Expose Taint.h to plugins
Reviewed By: NoQ, xazax.hun, steakhal

Differential Revision: https://reviews.llvm.org/D123155
2022-04-19 16:55:01 +02:00
Joseph Huber 944b25aee3 [OpenMP] Make Xopenmp-target args compile-only to silence warnings
Summary:
Previously we needed the `Xopenmp-target=` option during the linking
phase so the old offloading driver knew which items to extract and link
for the device. Now that the new driver has become the default this is
no longer necessary and will cause a warning to be emitted for the
unused argument. This should be silenced to avoid noise.
2022-04-19 08:42:43 -04:00
Roy Jacobson 76410040b9 Revert "[Concepts] Fix overload resolution bug with constrained candidates"
This reverts commit 454d1df942.
2022-04-19 07:51:21 -04:00
Balazs Benics 7984189826 [analyzer] Remove HasAlphaDocumentation tablegen enum value
D121387 simplified the doc url generation process, so we no longer need
the HasAlphaDocumentation enum entry. This patch removes that.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D121459
2022-04-19 12:14:27 +02:00
Roy Jacobson 454d1df942 [Concepts] Fix overload resolution bug with constrained candidates
When doing overload resolution, we have to check that candidates' parameter types are equal before trying to find a better candidate through checking which candidate is more constrained.
This revision adds this missing check and makes us diagnose those cases as ambiguous calls when the types are not equal.

Fixes GitHub issue https://github.com/llvm/llvm-project/issues/53640

Reviewed By: erichkeane

Differential Revision: https://reviews.llvm.org/D123182
2022-04-19 04:45:28 -04:00
Joseph Huber ae23be84cb [OpenMP] Make the new offloading driver the default
Previously an opt-in flag `-fopenmp-new-driver` was used to enable the
new offloading driver. After passing tests for a few months it should be
sufficiently mature to flip the switch and make it the default. The new
offloading driver is now enabled if there is OpenMP and OpenMP
offloading present and the new `-fno-openmp-new-driver` is not present.

The new offloading driver has three main benefits over the old method:
- Static library support
- Device-side LTO
- Unified clang driver stages

Depends on D122683

Differential Revision: https://reviews.llvm.org/D122831
2022-04-18 15:05:09 -04:00
Corentin Jabot daa6d7b250 [Clang] Use of decltype(capture) in parameter-declaration-clause
Partially implement the proposed resolution to CWG2569.

D119136 broke some libstdc++ code, as P2036R3, implemented as a DR to
C++11 made ill-formed some previously valid and innocuous code.

We resolve this issue to allow decltype(x) - but not decltype((x)
to appear in the parameter list of a lambda that capture x by copy.

Unlike CWG2569, we do not extend that special treatment to
sizeof/noexcept yet, as the resolution has not been approved yet
and keeping the review small allows a quicker fix of impacted code.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123909
2022-04-18 15:58:25 +02:00
Richard Smith b27430f9f4 Treat `std::move`, `forward`, etc. as builtins.
This is extended to all `std::` functions that take a reference to a
value and return a reference (or pointer) to that same value: `move`,
`forward`, `move_if_noexcept`, `as_const`, `addressof`, and the
libstdc++-specific function `__addressof`.

We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

This is a re-commit of
  fc30901096,
  a571f82a50, and
  64c045e25b
which were reverted in
  e75d8b7037
due to a crasher bug where CodeGen would emit a builtin glvalue as an
rvalue if it constant-folds.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123345
2022-04-17 13:26:16 -07:00
Bill Wendling 7f31b4a917 [randstruct] Enforce using a designated init for a randomized struct
A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values being assigned
to the wrong fields.

Differential Revision: https://reviews.llvm.org/D123763
2022-04-16 23:24:48 -07:00
Aaron Ballman 7692fc81e0 Revert "[randstruct] Enforce using a designated init for a randomized struct"
This reverts commit aed923b124.

It causes some buildbot test failures.
2022-04-16 11:11:32 -04:00
Vitaly Buka e75d8b7037 Revert "Treat `std::move`, `forward`, and `move_if_noexcept` as builtins."
Revert "Extend support for std::move etc to also cover std::as_const and"
Revert "Update test to handle opaque pointers flag flip."

It crashes on libcxx tests https://lab.llvm.org/buildbot/#/builders/85/builds/8174

This reverts commit fc30901096.
This reverts commit a571f82a50.
This reverts commit 64c045e25b.
2022-04-16 00:27:51 -07:00
Jun Zhang 7fde4e2213
Add some helpers to better check Scope's kind. NFC
Signed-off-by: Jun Zhang <jun@junz.org>
2022-04-16 11:31:40 +08:00
Shilei Tian e8760b51ee [Clang][OpenMP] Use bitfields for flags in `OMPAtomicDirective`
As suggested in D120290.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D123862
2022-04-15 21:34:28 -04:00
Joseph Huber 984a0dc386 [OpenMP] Use new offloading binary when embedding offloading images
The previous patch introduced the offloading binary format so we can
store some metada along with the binary image. This patch introduces
using this inside the linker wrapper and Clang instead of the previous
method that embedded the metadata in the section name.

Differential Revision: https://reviews.llvm.org/D122683
2022-04-15 20:35:26 -04:00
Richard Smith fc30901096 Extend support for std::move etc to also cover std::as_const and
std::addressof, plus the libstdc++-specific std::__addressof.

This brings us to parity with the corresponding GCC behavior.

Remove STDBUILTIN macro that ended up not being used.
2022-04-15 16:31:39 -07:00
Richard Smith 64c045e25b Treat `std::move`, `forward`, and `move_if_noexcept` as builtins.
We still require these functions to be declared before they can be used,
but don't instantiate their definitions unless their addresses are
taken. Instead, code generation, constant evaluation, and static
analysis are given direct knowledge of their effect.

This change aims to reduce various costs associated with these functions
-- per-instantiation memory costs, compile time and memory costs due to
creating out-of-line copies and inlining them, code size at -O0, and so
on -- so that they are not substantially more expensive than a cast.
Most of these improvements are very small, but I measured a 3% decrease
in -O0 object file size for a simple C++ source file using the standard
library after this change.

We now automatically infer the `const` and `nothrow` attributes on these
now-builtin functions, in particular meaning that we get a warning for
an unused call to one of these functions.

In C++20 onwards, we disallow taking the addresses of these functions,
per the C++20 "addressable function" rule. In earlier language modes, a
compatibility warning is produced but the address can still be taken.

The same infrastructure is extended to the existing MSVC builtin
`__GetExceptionInfo`, which is now only recognized in namespace `std`
like it always should have been.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123345
2022-04-15 14:09:45 -07:00
Bill Wendling aed923b124 [randstruct] Enforce using a designated init for a randomized struct
A randomized structure needs to use a designated or default initializer.
Using a non-designated initializer will result in values being assigned
to the wrong fields.

Differential Revision: https://reviews.llvm.org/D123763
2022-04-15 12:29:32 -07:00
Xiang Li 721651be24 [HLSL][clang][Driver] Support target profile command line option.
The target profile option(/T) decide the shader model when compile hlsl.
The format is shaderKind_major_minor like ps_6_1.
The shader model is saved as llvm::Triple is clang/llvm like
dxil-unknown-shadermodel6.1-hull.
The main job to support the option is translating ps_6_1 into
shadermodel6.1-pixel.
That is done inside tryParseProfile  at HLSL.cpp.

To integrate the option into clang Driver, a new DriverMode DxcMode is
created. When DxcMode is enabled, OSType for TargetTriple will be
forced into Triple::ShaderModel. And new ToolChain HLSLToolChain will
be created when OSType is Triple::ShaderModel.

In HLSLToolChain, ComputeEffectiveClangTriple is overridden to call
tryParseProfile when targetProfile option is set.

To make test work, Fo option is added and .hlsl is added for active
-xhlsl.

Reviewed By: beanz

Differential Revision: https://reviews.llvm.org/D122865

Patch by: Xiang Li <python3kgae@outlook.com>
2022-04-15 14:18:18 -05:00
Eli Friedman 4802edd1ac Fix size of flexible array initializers, and re-enable assertions.
In D123649, I got the formula for getFlexibleArrayInitChars slightly
wrong: the flexible array elements can be contained in the tail padding
of the struct.  Fix the formula to account for that.

With the fixed formula, we run into another issue: in some cases, we
were emitting extra padding for flexible arrray initializers. Fix
CGExprConstant so it uses a packed struct when necessary, to avoid this
extra padding.

Differential Revision: https://reviews.llvm.org/D123826
2022-04-15 12:09:57 -07:00
Shilei Tian 52e6a27690 Clean up `OMPAtomicDirective::Create` 2022-04-15 11:41:26 -04:00
Corentin Jabot 04000c2f92 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit  captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-15 16:50:52 +02:00
Jan Svoboda 7ed01ba88d [clang][deps] NFC: Inline function with single caller 2022-04-15 16:24:40 +02:00
Jan Svoboda 0b09b5d448 [clang][lex] NFC: Use FileEntryRef in PreprocessorLexer::getFileEntry()
This patch changes the return type of `PreprocessorLexer::getFileEntry()` so that its clients may stop using the deprecated APIs of `FileEntry`.

Reviewed By: bnbarham

Differential Revision: https://reviews.llvm.org/D123772
2022-04-15 15:16:17 +02:00
Aaron Ballman 33d3fc4466 [C89/C2x] Diagnose calls to a function without a prototype but passes arguments
This catches places where a function without a prototype is
accidentally used, potentially passing an incorrect number of
arguments, and is a follow-up to the work done in
https://reviews.llvm.org/D122895 and described in the RFC
(https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c).
The diagnostic is grouped under the new -Wdeprecated-non-prototypes
warning group and is enabled by default.

The diagnostic is disabled if the function being called was implicitly
declared (the user already gets an on-by-default warning about the
creation of the implicit function declaration, so no need to warn them
twice on the same line). Additionally, the diagnostic is disabled if
the declaration of the function without a prototype was in a location
where the user explicitly disabled deprecation warnings for functions
without prototypes (this allows the provider of the API a way to
disable the diagnostic at call sites because the lack of prototype is
intentional).
2022-04-15 09:08:54 -04:00
Eli Friedman 5955a0f937 Allow flexible array initialization in C++.
Flexible array initialization is a C/C++ extension implemented in many
compilers to allow initializing the flexible array tail of a struct type
that contains a flexible array. In clang, this is currently restricted
to C. But this construct is used in the Microsoft SDK headers, so I'd
like to extend it to C++.

For now, this doesn't handle dynamic initialization; probably not hard
to implement, but it's extra code, and I don't think it's necessary for
the expected uses.  And we explicitly fail out of constant evaluation.

I've added some additional code to assert that initializers have the
correct size, with or without flexible array init. This might catch
issues unrelated to flexible array init.

Differential Revision: https://reviews.llvm.org/D123649
2022-04-14 11:56:40 -07:00
Chris Bieneman 3efad612d2 [HLSL] Pointers are unsupported in HLSL
HLSL does not support pointers or references. This change generates
errors in sema for generating pointer, and reference types as well as
common operators (address-of, dereference, arrow), which are used with
pointers and are unsupported in HLSL.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123167
2022-04-14 13:32:51 -05:00
Chris Bieneman 1fdf952dee [HLSL] Add Semantic syntax, and SV_GroupIndex
HLSL has a language feature called Semantics which get attached to
declarations like attributes and are used in a variety of ways.

One example of semantic use is here with the `SV_GroupIndex` semantic
which, when applied to an input for a compute shader is pre-populated
by the driver with a flattened thread index.

Differential Revision: https://reviews.llvm.org/D122699

# Conflicts:
#	clang/include/clang/Basic/Attr.td
#	clang/include/clang/Basic/AttrDocs.td
2022-04-14 10:21:58 -05:00
Paul Robinson 52d346e715 [PS4] NFC refactor of PS4 toolchain class, prep for PS5 2022-04-14 05:37:39 -07:00
David Truby 53fd8db791 [Clang][AArch64][SVE] Allow subscript operator for SVE types
Undefined behaviour is just passed on to extract_element when the
index is out of bounds. Subscript on svbool_t is not allowed as
this doesn't really have meaningful semantics.

Differential Revision: https://reviews.llvm.org/D122732
2022-04-14 13:20:50 +01:00
Andrzej Warzynski 6c93e1d329 [flang][driver] Add support for `-mmlir`
The semantics of `-mmlir` are identical to `-mllvm`. The only notable
difference is that `-mmlir` options should be forwarded to MLIR rather
than LLVM.

Note that MLIR llvm::cl options are lazily constructed on demand (see
the definition of options in PassManagerOptions.cpp). This means that:
  * MLIR global options are only visible when explicitly initialised and
    displayed only when using `-mmlir --help`,
  * Flang and LLVM global options are always visible and displayed when
    using either `-mllvm -help` or `-mmlir --help`.

In other words, `-mmlir --help` is a superset of `-mllvm --help`. This is not
ideal, but we'd need to refactor all option definitions in Flang and
LLVM to improve this. I suggesting leaving this for later.

Differential Revision: https://reviews.llvm.org/D123297
2022-04-14 09:40:31 +00:00
Haojian Wu 6ba1b9075d Reland "[AST] Add a new TemplateKind for template decls found via a using decl.""
This is the template version of https://reviews.llvm.org/D114251.

This patch introduces a new template name kind (UsingTemplateName). The
UsingTemplateName stores the found using-shadow decl (and underlying
template can be retrieved from the using-shadow decl). With the new
template name, we can be able to find the using decl that a template
typeloc (e.g. TemplateSpecializationTypeLoc) found its underlying template,
which is useful for tooling use cases (include cleaner etc).

This patch merely focuses on adding the node to the AST.

Next steps:
- support using-decl in qualified template name;
- update the clangd and other tools to use this new node;
- add ast matchers for matching different kinds of template names;

Differential Revision: https://reviews.llvm.org/D123127
2022-04-14 11:04:55 +02:00
Jan Svoboda d79ad2f1db [clang][lex] NFCI: Use FileEntryRef in PPCallbacks::InclusionDirective()
This patch changes type of the `File` parameter in `PPCallbacks::InclusionDirective()` from `const FileEntry *` to `Optional<FileEntryRef>`.

With the API change in place, this patch then removes some uses of the deprecated `FileEntry::getName()` (e.g. in `DependencyGraph.cpp` and `ModuleDependencyCollector.cpp`).

Reviewed By: dexonsmith, bnbarham

Differential Revision: https://reviews.llvm.org/D123574
2022-04-14 10:46:12 +02:00
Richard Smith 836e610d93 Revert "[clang] Implement Change scope of lambda trailing-return-type"
This reverts commit c729d5be78.

This change breaks thread safety annotations on lambdas.
2022-04-13 21:34:08 -07:00
joker881 a4f47a99aa RISCV] Add clang builtins for CLZ instruction.
add intrinsic for CLZ

Reviewed By: craig.topper

Differential Revision: https://reviews.llvm.org/D121915
2022-04-14 12:29:15 +08:00
Fangrui Song ab8abeaf48 [Driver] Change CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL to affect driver default instead of cc1 default
The current cc1 CLANG_ENABLE_OPAQUE_POINTERS=on default difference is not ideal
in that people contribute %clang_cc1 tests may assume the default ON behavior,
which will cause failures on systems set to OFF.

cc1 option default dependent on CMake options should be used prudently
(generally avoided). We prefer to limit target differences to Driver.

Change the CLANG_ENABLE_OPAQUE_POINTERS_INTERNAL mechanism introduced in D123122
to use a driver default instead. This is similar to the mechanism used for the
-flegacy-pass-manager transition to new PM transition.

Reviewed By: #opaque-pointers, rsmith, aeubanks

Differential Revision: https://reviews.llvm.org/D123744
2022-04-13 16:58:00 -07:00
Corentin Jabot c729d5be78 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start
of the body would  be parsed in the parent scope, such that
captures would not be available to look up.

The scoping is changed to have an outer lambda scope,
followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope
between the start of the lambda (to which we want to attach
the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured
variable to (and several parts of clang assume captures are handled from
the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope
* Introduce a lambda scope
* Create the lambda class and call operator
* Add the init captures to the call operator context and the lambda scope.
  But the variables are not capured yet (because we don't know their type).
  Instead, explicit  captures are stored in a temporary map that
  conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context,
  we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point,
  we can switch (for the second time) inside the lambda context,
  unset the flag indicating that we have not parsed the lambda qualifiers,
  record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also
  transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope.
When trying to capture an implicit variable, if we are before the qualifiers of a lambda,
we need to remember that the variables are still in the parent's context (rather than in the call operator's).

This is a recommit of adff142dc2 after a fix in d8d793f29b

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-13 23:07:39 +02:00
Yitzhak Mandelbaum bbcf11f5af [clang][dataflow] Weaken abstract comparison to enable loop termination.
Currently, when the framework is used with an analysis that does not override
`compareEquivalent`, it does not terminate for most loops. The root cause is the
interaction of (the default implementation of) environment comparison
(`compareEquivalent`) and the means by which locations and values are
allocated. Specifically, the creation of certain values (including: reference
and pointer values; merged values) results in allocations of fresh locations in
the environment. As a result, analysis of even trivial loop bodies produces
different (if isomorphic) environments, on identical inputs. At the same time,
the default analysis relies on strict equality (versus some relaxed notion of
equivalence). Together, when the analysis compares these isomorphic, yet
unequal, environments, to determine whether the successors of the given block
need to be (re)processed, the result is invariably "yes", thus preventing loop
analysis from reaching a fixed point.

There are many possible solutions to this problem, including equivalence that is
less than strict pointer equality (like structural equivalence) and/or the
introduction of an explicit widening operation. However, these solutions will
require care to be implemented correctly. While a high priority, it seems more
urgent that we fix the current default implentation to allow
termination. Therefore, this patch proposes, essentially, to change the default
comparison to trivally equate any two values. As a result, we can say precisely
that the analysis will process the loop exactly twice -- once to establish an
initial result state and the second to produce an updated result which will
(always) compare equal to the previous. While clearly unsound -- we are not
reaching a fix point of the transfer function, in practice, this level of
analysis will find many practical issues where a single iteration of the loop
impacts abstract program state.

Note, however, that the change to the default `merge` operation does not affect
soundness, because the framework already produces a fresh (sound) abstraction of
the value when the two values are distinct. The previous setting was overly
conservative.

Differential Revision: https://reviews.llvm.org/D123586
2022-04-13 19:49:50 +00:00
Mehdi Amini 26eec9e9db Revert "[clang] Implement Change scope of lambda trailing-return-type"
This reverts commit adff142dc2.
This broke clang bootstrap: it made existing C++ code in LLVM invalid:

llvm/include/llvm/CodeGen/LiveInterval.h:630:53: error: captured variable 'Idx' cannot appear here
              [=](std::remove_reference_t<decltype(*Idx)> V,
                                                    ^
2022-04-13 19:35:13 +00:00
Corentin Jabot adff142dc2 [clang] Implement Change scope of lambda trailing-return-type
Implement P2036R3.

Captured variables by copy (explicitely or not), are deduced
correctly at the point we know whether the lambda is mutable,
and ill-formed before that.

Up until now, the entire lambda declaration up to the start of the body would be parsed in the parent scope, such that capture would not be available to look up.

The scoping is changed to have an outer lambda scope, followed by the lambda prototype and body.

The lambda scope is necessary because there may be a template scope between the start of the lambda (to which we want to attach the captured variable) and the prototype scope.

We also need to introduce a declaration context to attach the captured variable to (and several parts of clang assume captures are handled from the call operator context), before we know the type of the call operator.

The order of operations is as follow:

* Parse the init capture in the lambda's parent scope

* Introduce a lambda scope

* Create the lambda class and call operator

* Add the init captures to the call operator context and the lambda scope. But the variables are not capured yet (because we don't know their type).
Instead, explicit  captures are stored in a temporary map that conserves the order of capture (for the purpose of having a stable order in the ast dumps).

* A flag is set on LambdaScopeInfo to indicate that we have not yet injected the captures.

* The parameters are parsed (in the parent context, as lambda mangling recurses in the parent context, we couldn't mangle a lambda that is attached to the context of a lambda whose type is not yet known).

* The lambda qualifiers are parsed, at this point We can switch (for the second time) inside the lambda context, unset the flag indicating that we have not parsed the lambda qualifiers,
record the lambda is mutable and capture the explicit variables.

* We can parse the rest of the lambda type, transform the lambda and call operator's types and also transform the call operator to a template function decl where necessary.

At this point, both captures and parameters can be injected in the body's scope. When trying to capture an implicit variable, if we are before the qualifiers of a lambda, we need to remember that the variables are still in the parent's context (rather than in the call operator's).

Reviewed By: aaron.ballman, #clang-language-wg, ChuanqiXu

Differential Revision: https://reviews.llvm.org/D119136
2022-04-13 20:00:03 +02:00
Yaxun (Sam) Liu 0424b5115c [CUDA][HIP] Fix host used external kernel in archive
For -fgpu-rdc, a host function may call an external kernel
which is defined in an archive of bitcode. Since this external
kernel is only referenced in host function, the device
bitcode does not contain reference to this external
kernel, then the linker will not try to resolve this external
kernel in the archive.

To fix this issue, host-used external kernels and device
variables are tracked. A global array containing pointers
to these external kernels and variables is emitted which
serves as an artificial references to the external kernels
and variables used by host.

Reviewed by: Artem Belevich

Differential Revision: https://reviews.llvm.org/D123441
2022-04-13 10:47:16 -04:00
Aaron Ballman 385e7df330 Correctly diagnose prototype redeclaration errors in C
We did not implement C99 6.7.5.3p15 fully in that we missed the rule
for compatible function types where a prior declaration has a prototype
and a subsequent definition (not just declaration) has an empty
identifier list or an identifier list with a mismatch in parameter
arity. This addresses that situation by issuing an error on code like:

void f(int);
void f() {} // type conflicts with previous declaration

(Note: we already diagnose the other type conflict situations
appropriately, this was the only situation we hadn't covered that I
could find.)
2022-04-13 08:21:31 -04:00
Andrzej Warzynski dd56939a4b [flang][driver] Add support for generating LLVM bytecode files
Support for generating LLVM BC files is added in Flang's compiler and
frontend drivers. This requires the `BitcodeWriterPass` pass to be run
on the input LLVM IR module and is implemented as a dedicated frontend
aciton. The new functionality as seen by the user (compiler driver):
```
flang-new -c -emit-llvm file.90
```
or (frontend driver):
```
flang-new -fc1 -emit-llvm-bc file.f90
```

The new behaviour is consistent with `clang` and `clang -cc1`.

Differential Revision: https://reviews.llvm.org/D123211
2022-04-13 10:19:56 +00:00
Nikita Popov 2978d02681 [Clang] Remove support for legacy pass manager
This removes the -flegacy-pass-manager and
-fno-experimental-new-pass-manager options, and the corresponding
support code in BackendUtil. The -fno-legacy-pass-manager and
-fexperimental-new-pass-manager options are retained as no-ops.

Differential Revision: https://reviews.llvm.org/D123609
2022-04-13 10:21:42 +02:00
Haojian Wu 93471e65df [clang] NFC, move CompilerInvocation::setLangDefaults to LangOptions.h
The function is moved from clangFrontend to clangBasic, which allows tools
(e.g. clang pseudoparser) which don't depend on clangFrontend to use.

Differential Revision: https://reviews.llvm.org/D121375
2022-04-13 09:44:39 +02:00
Chuanqi Xu 36de2d639e [NFC] [AST] Reduce the size of TemplateParmPosition
I found this when reading the codes. I think it makes sense to reduce
the space for TemplateParmPosition. It is hard to image the depth of
template parameter is larger than 2^20 and the index is larger than
2^12. So I think the patch might be reasonable.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D123298
2022-04-13 10:56:13 +08:00
Daniel Grumberg 7443a504bf [clang][extract-api] Add support for true anonymous enums
Anonymous enums without a typedef should have a "(anonymous)" identifier.

Differential Revision: https://reviews.llvm.org/D123533
2022-04-12 20:42:17 +01:00
Arthur Eubanks 9faab435a3 [docs] Mention that we are in the process of removing the legacy PM for the optimization pipeline
And remove references to flags to turn it off.

Reviewed By: nikic, MaskRay

Differential Revision: https://reviews.llvm.org/D123547
2022-04-12 10:47:58 -07:00