As captured in issue #108044, HLSL 202x is the target language mode for
conformance for Clang. Earlier language modes will be a best effort and
prioritized after 2020x. To make this easier and reduce our testing
complexity we want to make 202x the default language mode now, and align
all earlier modes to match 202x (except where we explicitly deviate).
This change has the following concrete changes:
* All older language modes gain `CPlusPlus11` as a base
* The default language mode for HLSL sources is changed to 202x
* A few test cases are updated to resolve differences in generated
diagnostics.
Second to last change for #108044
This change adds a new HLSL 202y language mode. Currently HLSL 202y is
planned to add `auto` and `constexpr`.
This change updates extension diagnostics to state that lambadas are a
"clang HLSL" extension (since we have no planned release yet to include
them), and that `auto` is a HLSL 202y extension when used in earlier
language modes.
Note: This PR does temporarily work around some differences between HLSL
2021 and 202x in Clang by changing test cases to explicitly specify
202x. A subsequent PR will update 2021's language flags to match 202x.
Before llvm20, (void)__sync_fetch_and_add(...) always generates locked
xadd insns. In linux kernel upstream discussion [1], it is found that
for arm64 architecture, the original semantics of
(void)__sync_fetch_and_add(...), i.e., __atomic_fetch_add(...), is
preferred in order for jit to emit proper native barrier insns.
In llvm commits [2] and [3], (void)__sync_fetch_and_add(...) will
generate the following insns:
- for cpu v1/v2: locked xadd insns to keep backward compatibility
- for cpu v3/v4: __atomic_fetch_add() insns
To ensure proper barrier semantics for (void)__sync_fetch_and_add(...),
cpu v3/v4 is recommended.
This patch enables cpu=v3 as the default cpu version. For users wanting
to use cpu v1, -mcpu=v1 needs to be explicitly added to clang/llc
command line.
[1]
https://lore.kernel.org/bpf/ZqqiQQWRnz7H93Hc@google.com/T/#mb68d67bc8f39e35a0c3db52468b9de59b79f021f
[2] https://github.com/llvm/llvm-project/pull/101428
[3] https://github.com/llvm/llvm-project/pull/106494
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.
If both `-fptrauth-init-fini` and `-fptrauth-calls` are passed, sign
function pointers in `llvm.global_ctors` and `llvm.global_dtors` with
constant discriminator 0xD9D4
(`ptrauth_string_discriminator("init_fini")`). Additionally, if
`-fptrauth-init-fini-address-discrimination` is passed, address
discrimination is used for signing (otherwise, just constant
discriminator is used).
For address discrimination, we use it's special form since uses of
`llvm.global_{c|d}tors` are disallowed (see
`Verifier::visitGlobalVariable`) and we can't emit `getelementptr`
expressions referencing these special arrays. A signed ctor/dtor pointer
with special address discrimination applied looks like the following:
```
ptr ptrauth (ptr @foo, i32 0, i64 55764, ptr inttoptr (i64 1 to ptr))
```
Fix the location of `diag::note_constexpr_uninitialized_base`, make it
same as current interpreter.
This PR does not print type name with namespacethat was used to improve
the current interpreter's type dump of base class type.
---------
Signed-off-by: yronglin <yronglin777@gmail.com>
Currently `__FINITE_MATH_ONLY__` is set when `FiniteMathOnly`. And
`FiniteMathOnly` is set when `NoHonorInfs` && `NoHonorNans` is true. But
what happens one of the latter flags is false?
To avoid potential inconsistencies, the internal option `FiniteMathOnly`
is removed option and the macro `__FINITE_MATH_ONLY__` is set when
`NoHonorInfs` && `NoHonorNans`.
Implement tests for the following PAuth-related features:
- driver, preprocessor and ELF codegen tests for type_info vtable
pointer discrimination #99726;
- driver, preprocessor, and ELF codegen (emitting function attributes) +
sema (emitting errors) tests for indirect gotos signing #97647;
- ELF codegen tests for ubsan type checks + auth #99590;
- ELF codegen tests for constant global init with polymorphic MI #99741;
- ELF codegen tests for C++ member function pointers auth #99576.
This implements the __builtin_cpu_init and __builtin_cpu_supports
builtin routines based on the compiler runtime changes in
https://github.com/llvm/llvm-project/pull/85790.
This is inspired by https://github.com/llvm/llvm-project/pull/85786.
Major changes are a) a restriction in scope to only the builtins (which
have a much narrower user interface), and the avoidance of false
generality. This change deliberately only handles group 0 extensions
(which happen to be all defined ones today), and avoids the tblgen
changes from that review.
I don't have an environment in which I can actually test this, but @BeMg
has been kind enough to report that this appears to work as expected.
Before this can make it into a release, we need a change such as
https://github.com/llvm/llvm-project/pull/99958. The gcc docs claim that
cpu_support can be called by "normal" code without calling the cpu_init
routine because the init routine will have been called by a high
priority constructor. Our current compiler-rt mechanism does not do
this.
As discussed at the last sync-up call, mark Zacas as experimental until
this ABI issue is resolved
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/444>.
Don't return Zacas in getHostCPUFeatures (leaving a TODO there) as even if requesting detection of "native" features, the user likely doesn't want to automatically opt in to experimental codegen.
The newly added strings `la64v1.0` and `la64v1.1` in `-march` are as
described in LoongArch toolchains conventions (see [1]).
The target-cpu/feature attributes are forwarded to compiler when
specifying particular `-march` parameter. The default cpu `loongarch64`
is returned when archname is `la64v1.0` or `la64v1.1`.
In addition, this commit adds `la64v1.0`/`la64v1.1` to
"__loongarch_arch" and adds definition for macro "__loongarch_frecipe".
[1]: https://github.com/loongson/la-toolchain-conventions
`#pragma mc_func` is an IBM XL feature that should be replaced by inline
assembly. This PR adds an option `-ferr-pragma-mc-func-aix` to detect
uses of `#pragma mc_func` and reports an error if the option is in
effect. If `-fno-err-pragma-mc-func-aix` is in effect, `#pragma mc_func`
is ignored even if `-Werror=unknown-pragmas` is in effect.
It seems for C++ lexer has some caching ability which doesn't expect
injecting "new" tokens in the middle of the cache. Technically #embed
tokens are not completely new since they have already been read from the
file and there was #embed annotation token in this place, so set
`reinject` flag for them to silence assertion.
This patch makes remaining cases of #embed to emit int type since there
is an agreement to do that for C. C++ is being discussed, but in general
we don't want to produce different types for C and C++.
The 2022 SME2.1and SVE2.1 feature macros are missing from Clang. Passing
'-target-feature +sve2p1' and 'target-feature +sme2p1' should prompt
Clang to define __ARM_FEATURE_SVE2p1 and __ARM_FEATURE_SME2p1
respectively, including their prerequisits..
This patch includes __ARM_FEATURE_SVE2p1 and __ARM_FEATURE_SME2p1, plus
a clang preprocessor test for each. It also ensures that the Clang macro
builder is used in a consistent fashion across Targets/AArch64.cpp.
The specification for SVE2.1 is documented in the latest (2024 Q1) ACLE
release: https://github.com/ARM-software/acle/releases . SME2p1 is not
yet featured in ACLE documentation but its features are described under
https://developer.arm.com/documentation/ddi0487/latest/
1. Dead code in `LookupEmbedFile`. The loop always exited on the first
iteration. This was also causing a bug of not checking all directories
provided by `--embed-dir`.
2. Use of uninitialized variable `CurTok` in `LexEmbedParameters`. It
was used to initialize the field which seems to be unused. Removed
unused field, this way `CurTok` should be initialized by Lex method.
This reverts commit 06518cea3905556d8d1eea4088132ebb234bfdab.
This reverts commit 05275b05ca58e4d015eea1503f120e6967ef1b91.
This reverts commit c0c4ad5d9a6e05e0b1f5f98ce2e08d479b281be8.
Whenever these tests change, it's difficult to see why they don't match,
and the diff after you've fixed them isn't easy to grok. By splitting
them with a sed pipe, we fix both issues simultaneously.
When #embed appears in an initializer list, we may choose a "fast path"
if the target declaration is a char array. We simply initialize it with
string literal that contains embedded data. However we need to be
careful when checking that we actually can use this "fast path" since
char array may be nested in a struct.
This set of instructions was only supported by AMD chips starting in
the K6-2 (introduced 1998), and before the "Bulldozer" family
(2011). They were never much used, as they were effectively superseded
by the more-widely-implemented SSE (first implemented on the AMD side
in Athlon XP in 2001).
This is being done as a predecessor towards general removal of MMX
register usage. Since there is almost no usage of the 3DNow!
intrinsics, and no modern hardware even implements them, simple
removal seems like the best option.
(Clang half originally uploaded in https://reviews.llvm.org/D94213)
Works towards issue #41665 and issue #98272.
Instead of playing "whack a mole" with places where #embed should be
expanded as comma-separated list, just inject each byte as a token back
into the stream, separated by commas.
Both of them are ratified now.
https://wiki.riscv.org/display/HOME/Ratified+Extensions
This patch does not set them to non-experimental, since Zicfilp lacks
lld support and Zicfiss also lacks compiler-rt/libunwind support.
