Fixes: #113187
Avoid to create init function since clang does not support global
variable with flexible array init.
It will cause assertion failure later.
According to [P0533R9](https://wg21.link/P0533R9), the C++ standard
library functions corresponding to the C macros in `[c.math.abs]` are
now `constexpr`.
To implement this feature in libc++, we must make the built-in abs
function `constexpr`. This patch adds the implementation of a
`constexpr` abs function for the current constant evaluator and the new
bytecode interpreter.
It is important to note that in 2's complement systems, the absolute
value of the most negative value is out of range. In gcc, it will result
in an out-of-range error and will not be evaluated as constants. We
follow the same approach here.
In #99726, `-fptrauth-type-info-vtable-pointer-discrimination` was
introduced, which is intended to enable type and address discrimination
for type_info vtable pointers. However, some codegen logic for actually
enabling address discrimination was missing. This patch addresses the
issue.
Fixes#101716
We have a dedicated test to check the target-features for FMV
(clang/test/CodeGen/aarch64-fmv-dependencies.c) therefore I am removing
the autogenerated checks from irrelevant tests since the noise is making
it harder to review actual codegen changes.
According to https://developer.arm.com/documentation/102105/latest Arm
Architecture Reference Manual for A-profile architecture: Known issues
2.206 D22789
In section C5.2.25 "SSBS, Speculative Store Bypass Safe", under the
heading 'Configurations', the text that reads:
"This register is present only when FEAT_SSBS is implemented. Otherwise,
direct accesses to SSBS are UNDEFINED."
is changed to read:
"This register is present only when FEAT_SSBS2 is implemented.
Otherwise, direct accesses to SSBS are UNDEFINED."
This suggests that it's not worth splitting FEAT_SSBS2 from FEAT_SSBS in
the compiler, since FEAT_SSBS cannot be used for predicating the MRS/MSR
instructions. Those can access PSTATE.SSBS only when FEAT_SSBS2 is
available. Moreover, there are no hardware implementations which
implement FEAT_SSBS without FEAT_SSBS2, therefore unifying these
features in the specification should not be a regression for feature
detection.
Approved in ACLE as https://github.com/ARM-software/acle/pull/350
Summary:
This patch causes us to respect the `-fconvergent-functions` and
`-fno-convergent-functions` options correctly. GPU targets should have
this set all the time, but we now offer `-fno-convergent-functions` to
opt-out if you want to test broken behavior. This munged about with a
lot of the old weird logic, but I don't think it makes any real changes.
This was originally added in https://reviews.llvm.org/D142268 to have
LLDB display variable typenames that benefit from suppressing defaulted
template arguments.
We currently represent template aliases as `DW_AT_typedef`s instead of
`DW_TAG_template_alias`. This means for types like:
```
template <class _Tp>
using __remove_cv_t = __remove_cv(_Tp);
template <class _Tp>
using remove_cv_t = __remove_cv_t<_Tp>;
template<typename T>
class optional {
using value_type = T;
remove_cv_t<value_type> __val_;
}
```
we would generate DWARF like:
```
0x0000274f: DW_TAG_typedef
DW_AT_type (0x0000000000002758 "__remove_cv_t<value_type>")
DW_AT_name ("remove_cv_t<value_type>")
```
This is an actual libc++ type layout introduced in
https://github.com/llvm/llvm-project/pull/110355, and uncovered a
shortcoming of LLDB's data-formatter infrastructure, where we cache
formatters on the contents of `DW_AT_name` (which currently wouldn't be
a fully resolved typename for template specializations).
To unblock the libc++ change, I think we can revert this without much
fallout.
Then we have two options for follow-up (or do both):
1. reland this but adjust the LLDB formatter cache so it doesn't cache
formatters for template specializations
2. implement support for `DW_TAG_template_alias` in LLDB (and make Clang
generate them by default).
Fix#108015
The `mangleNameOrStandardSubstitution` function does not add the RD type
into the substitution, which causes the mangling of the \<base type\> to
be incorrect.
Rename `mangleNameOrStandardSubstitution` to `mangleCXXRecordDecl` and add `Record` as a substitution
This is primarily meant to address the issue identified in #109182,
around incorrect usage of `-fsycl-is-device`; we now have AMDGCN
flavoured SPIR-V which retains the desired behaviour around the default
AS and does not depend on the SYCL language being enabled to do so.
Overall, there are three changes:
1. We unconditionally use the `SPIRDefIsGen` AS map for AMDGCNSPIRV
target, as there is no case where the hack of setting default to private
would be desirable, and it can be used for languages other than OCL/HIP;
2. We implement `SPIRVTargetCodeGenInfo::getGlobalVarAddressSpace` for
SPIR-V in general, because otherwise using it from languages other than
HIP or OpenCL would yield 0, incorrectly;
3. We remove the incorrect usage of `-fsycl-is-device`.
And fix the diagnostics for __builtin_is_constant_evaluated(). We can be
in a non-constant context, but calling an immediate function always
makes the context constant for the duration of that call.
Set up these tests so these are marked as unsupported when targeting
z/OS. Most would already be unsupported if you ran lit on z/OS. However,
they also need to be unsupported if the default triple is z/OS.
The mangling compatibility being tested here changed between Clang 17
and 18, not between 16 and 17, so change the "old" version to 17.
As requested by @ahatanak in [post-commit
review](7421dd55a1 (commitcomment-128651446)).
An 'if' statement introduces a scope, but in some cases the conditional
branch to the then/else blocks had a debug-info attribution that did not
include the scope. This led to some inefficiency in the DWARF line
table.
Originally I tried spliting these features in the compiler with
https://github.com/llvm/llvm-project/pull/101712, but we decided to lump
those features in the ACLE specification (see
https://github.com/ARM-software/acle/pull/346). Since there are no
hardware implementations out there which implement ls64 without ls64_v
or ls64_accdata, this shouldn't be a regression for feature detection.
This implements our original design now that LLVM is comfortable with
structs and arrays of scalable vector types. All SVE ACLE intrinsics
already use struct types so the effect of this change is purely the
types used for alloca and function parameters.
There should be no C/C++ user visible change with this patch.
This patch enable the function multiversion(FMV) and `target_clones`
attribute for RISC-V target.
The proposal of `target_clones` syntax can be found at the
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/48 (which has
landed), as modified by the proposed
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/85 (which adds the
priority syntax).
It supports the `target_clones` function attribute and function
multiversioning feature for RISC-V target. It will generate the ifunc
resolver function for the function that declared with target_clones
attribute.
The resolver function will check the version support by runtime object
`__riscv_feature_bits`.
For example:
```
__attribute__((target_clones("default", "arch=+ver1", "arch=+ver2"))) int bar() {
return 1;
}
```
the corresponding resolver will be like:
```
bar.resolver() {
__init_riscv_feature_bits();
// Check arch=+ver1
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION1) == BITMASK_OF_VERSION1) {
return bar.arch=+ver1;
} else {
// Check arch=+ver2
if ((__riscv_feature_bits.features[0] & BITMASK_OF_VERSION2) == BITMASK_OF_VERSION2) {
return bar.arch=+ver2;
} else {
// Default
return bar.default;
}
}
}
```
Clang should only emit an available_externally vtable when there are no
unused virtual inline functions. Currently, if such such a function is
declared without inline inside the class, but is defined inline outside
the class, Clang might emit the vtable as available_externally. This
happens because Clang only considers the declarations of vtable entries,
but not the definitions. This patch addresses this by inspecting the
definitions in addition to the declarations.
Add nuw attribute to inbounds GEPs where the expression used to form the
GEP is an addition of unsigned indices.
Relands #105496, which was reverted because it exposed a miscompilation
arising from #98608. This is now fixed by #106512.
This was accidentally matching a metadata record that happend to have
three elements, but wasn't the record of interest. Add CHECKs to make
sure we've found the correct record.
As agreed on https://github.com/itanium-cxx-abi/cxx-abi/issues/109 these
placeholders should be mangled as a `template-prefix` production.
```
<template-prefix> ::= <template unqualified-name> # global template
::= <prefix> <template unqualified-name> # nested template
::= <template-param> # template template parameter
::= <substitution>
```
Previous to this patch, the template template parameter case was not
handled, and template template parameters were incorrectly being handled
as unqualified-names.
Before #95202, DeducedTemplateType was not canonicalized correctly, so
that template template parameter declarations were retained
uncanonicalized.
After #95202, they are correctly canonicalized, but this now leads to
these TTPs being anonymous entities, where the mangling implementation
correctly doesn't expect an anonymous declaration of this kind, leading
to a crash.
Fixes#106182.
For mobile applications, it's common for global destructors to never be
called (because the applications have their own lifecycle independent of
the standard C runtime), but threads are created and destroyed as normal
and so thread-local destructors are still called. -fno-static-c++-destructors
omits unnecessary global destructors, which is useful for code size, but
it also omits thread-local destructors, which is unsuitable. Add a
ternary `-fc++-static-destructors={all,none,thread-local}` option
instead to allow omitting only global destructors.
Reapply https://github.com/llvm/llvm-project/pull/102848.
The description in this PR will detail the changes from the reverted
original PR above.
For `auto&&` return types that can partake in reference collapsing we
weren't properly handling that mangling that can arise.
When collapsing occurs an inner reference is created with the collapsed
reference type. If we return `int&` from such a function then an inner
reference of `int&` is created within the `auto&&` return type.
`getPointeeType` on a reference type goes through all inner references
before returning the pointee type which ends up being a builtin type,
`int`, which is unexpected.
We can use `getPointeeTypeAsWritten` to get the `AutoType` as expected
however for the instantiated template declaration reference collapsing
already occurred on the return type. This means `auto&&` is turned into
`auto&` in our example above.
We end up mangling an lvalue reference type.
This is unintended as MSVC mangles on the declaration of the return
type, `auto&&` in this case, which is treated as an rvalue reference.
```
template<class T>
auto&& AutoReferenceCollapseT(int& x) { return static_cast<int&>(x); }
void test()
{
int x = 1;
auto&& rref = AutoReferenceCollapseT<void>(x); // "??$AutoReferenceCollapseT@X@@YA$$QEA_PAEAH@Z"
// Mangled as an rvalue reference to auto
}
```
If we are mangling a template with a placeholder return type we want to
get the first template declaration and use its return type to do the
mangling of any instantiations.
This fixes the bug reported in the original PR that caused the revert
with libcxx `std::variant`.
I also tested locally with libcxx and the following test code which
fails in the original PR but now works in this PR.
```
#include <variant>
void test()
{
std::variant<int> v{ 1 };
int& r = std::get<0>(v);
(void)r;
}
```
`x86_64-sie-ps5` is the triple we share with PS5 toolchain users who
have reason to care about such things. The vast majority of PS5 checks
and tests already use this variant. Quashing the handful of stragglers
will help prevent future copy+paste of the discouraged variant.
Summary:
Currently we have some sema checks to make sure users don't apply
kernel-only attributes to non-kernel functions. However, this currently
did not correctly check for bare NVPTX / AMDGPU kernel attributes,
making it impossible to use them at all w/o CUDA enabled. This patch
fixes that by checking for the calling convention / attributes directly.
It cause builds to start failing with
Invalid type expected
UNREACHABLE executed at clang/lib/AST/MicrosoftMangle.cpp:2551!
see comments on the PR.
> Partial fix for https://github.com/llvm/llvm-project/issues/92204.
> This PR just fixes VS2019+ since that is the suite of compilers that I
> require link compatibility with at the moment.
> I still intend to fix VS2017 and to update llvm-undname in future PRs.
> Once those are also finished and merged I'll close out
> https://github.com/llvm/llvm-project/issues/92204.
> I am hoping to get the llvm-undname PR up in a couple of weeks to be
> able to demangle the VS2019+ name mangling.
>
> MSVC 1920+ mangles placeholder return types for non-templated functions
> with "@".
> For example `auto foo() { return 0; }` is mangled as `?foo@@YA@XZ`.
>
> MSVC 1920+ mangles placeholder return types for templated functions as
> the qualifiers of the AutoType followed by "_P" for `auto` and "_T" for
> `decltype(auto)`.
> For example `template<class T> auto foo() { return 0; }` is mangled as
> `??$foo@H@@YA?A_PXZ` when `foo` is instantiated as follows `foo<int>()`.
>
> Lambdas with placeholder return types are still mangled with clang's
> custom mangling since MSVC lambda mangling hasn't been deciphered yet.
> Similarly any pointers in the return type with an address space are
> mangled with clang's custom mangling since that is a clang extension.
>
> We cannot augment `mangleType` to support this mangling scheme as the
> mangling schemes for variables and functions differ.
> auto variables are encoded with the fully deduced type where auto return
> types are not.
> The following two functions with a static variable are mangled the same
> ```
> template<class T>
> int test()
> {
> static int i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
> return i;
> }
>
> template<class T>
> int test()
> {
> static auto i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
> return i;
> }
> ```
> Inside `mangleType` once we get to mangling the `AutoType` we have no
> context if we are from a variable encoding or some other encoding.
> Therefore it was easier to handle any special casing for `AutoType`
> return types with a separate function instead of using the `mangleType`
> infrastructure.
This reverts commit e0d173d44161bf9b68243845666d58999e74f759
and the wollow-up fa343be414f9364911b947f109f3df5539e23068.
Partial fix for https://github.com/llvm/llvm-project/issues/92204.
This PR just fixes VS2019+ since that is the suite of compilers that I
require link compatibility with at the moment.
I still intend to fix VS2017 and to update llvm-undname in future PRs.
Once those are also finished and merged I'll close out
https://github.com/llvm/llvm-project/issues/92204.
I am hoping to get the llvm-undname PR up in a couple of weeks to be
able to demangle the VS2019+ name mangling.
MSVC 1920+ mangles placeholder return types for non-templated functions
with "@".
For example `auto foo() { return 0; }` is mangled as `?foo@@YA@XZ`.
MSVC 1920+ mangles placeholder return types for templated functions as
the qualifiers of the AutoType followed by "_P" for `auto` and "_T" for
`decltype(auto)`.
For example `template<class T> auto foo() { return 0; }` is mangled as
`??$foo@H@@YA?A_PXZ` when `foo` is instantiated as follows `foo<int>()`.
Lambdas with placeholder return types are still mangled with clang's
custom mangling since MSVC lambda mangling hasn't been deciphered yet.
Similarly any pointers in the return type with an address space are
mangled with clang's custom mangling since that is a clang extension.
We cannot augment `mangleType` to support this mangling scheme as the
mangling schemes for variables and functions differ.
auto variables are encoded with the fully deduced type where auto return
types are not.
The following two functions with a static variable are mangled the same
```
template<class T>
int test()
{
static int i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
return i;
}
template<class T>
int test()
{
static auto i = 0; // "?i@?1???$test@H@@YAHXZ@4HA"
return i;
}
```
Inside `mangleType` once we get to mangling the `AutoType` we have no
context if we are from a variable encoding or some other encoding.
Therefore it was easier to handle any special casing for `AutoType`
return types with a separate function instead of using the `mangleType`
infrastructure.
Such struct types:
```
struct {
struct{} a;
long long b;
};
stuct {
struct{} a;
double b;
};
```
For such structures, Lo is NoClass and Hi is Integer/SSE. And when this
structure argument is passed, the high part is passed at offset 8 in
memory. So we should do special handling for these types in
EmitVAArg.Fix https://github.com/llvm/llvm-project/issues/79790 and fix
https://github.com/llvm/llvm-project/issues/86371.
Generate nuw GEPs for struct member accesses, as inbounds + non-negative
implies nuw.
Regression tests are updated using update scripts where possible, and by
find + replace where not.
This patch is motivated by the debug-info issue in
https://github.com/llvm/llvm-project/issues/48909. Clang is currently
emitting the `DW_AT_artificial` attribute on debug-info entries for
structured bindings whereas GCC does not. GCC's interpretation of the
DWARF spec is more user-friendly in this regard, so we would like to do
the same in Clang. [`CGDebugInfo` uses `isImplicit` to decide which
variables to mark
artificial](0c4023ae3b/clang/lib/CodeGen/CGDebugInfo.cpp (L4783-L4784))
(e.g., `ImplicitParamDecls`, compiler-generated variables, etc.). But
for the purposes of debug-info, when we say "artificial", what we really
mean in many cases is: "not explicitly spelled out in source".
`VarDecl`s that back tuple-like bindings are [technically
compiler-generated](https://github.com/llvm/llvm-project/issues/48909#issuecomment-2238976579),
but that is a confusing notion for debug-info, since these bindings
*are* spelled out in source. The [documentation for
`isImplicit`](68a0d0c762/clang/include/clang/AST/DeclBase.h (L596-L600))
does to some extent imply that implicit variables aren't written in
source.
This patch adds another condition to deciding whether a `VarDecl` should
be marked artificial. Specifically, don't treat structured bindings as
artificial.
**Main alternatives considered**
1. Don't use `isImplicit` in `CGDebugInfo` when determining whether to
add `DW_AT_artificial`. Instead use some other property of the AST that
would tell us whether a node was explicitly spelled out in source or not
* Considered using `SourceRange` or `SourceLocation` to tell us this,
but didn't find a good way to, e.g., correctly identify that the
implicit `this` parameter wasn't spelled out in source (as opposed to an
unnamed parameter in a function declaration)
2. We could've also added a bit to `VarDeclBitFields` that indicates
that a `VarDecl` is a holding var, but the use-case didn't feel like
good enough justification for this
3. Don't set the `VarDecl` introduced as part of a tuple-like
decomposition as implicit.
* This may affect AST matching/traversal and this specific use-case
wasn't enough to justify such a change
Fixes https://github.com/llvm/llvm-project/issues/48909
Enabling __ptr32 keyword to support in Clang for z/OS. It is represented
by addrspace(1) in LLVM IR. Unlike existing implementation, __ptr32 is
not mangled into symbol names for z/OS.
Reland https://github.com/llvm/llvm-project/pull/75912
The differences of this PR between
https://github.com/llvm/llvm-project/pull/75912 are:
- Fixed a regression in `Decl::isInAnotherModuleUnit()` in DeclBase.cpp
pointed by @mizvekov and add the corresponding test.
- Fixed the regression in windows
https://github.com/llvm/llvm-project/issues/97447. The changes are in
`CodeGenModule::getVTableLinkage` from
`clang/lib/CodeGen/CGVTables.cpp`. According to the feedbacks from MSVC
devs, the linkage of vtables won't affected by modules. So I simply
skipped the case for MSVC.
Given this is more or less fundamental to the use of modules. I hope we
can backport this to 19.x.
