When '-march' with LASX feature and '-mno-lsx' options are used
together, '-mno-lsx' fails to disable LASX, leaving
'HasFeatureLASX=true' and causing incorrect '__loongarch_sx/asx=1' macro
definition.
Fixes https://github.com/loongson-community/discussions/issues/95
(cherry picked from commit 2ecbfc0beb42abbbd2c3d28bfd576b38c44a5b46)
This cherry-picks 3b4c51bb3243a02526313c51207a674139b67a00 and
beffd1509af7b12eeab0d5ae85b2f8322e039287 to 20.x.
Which are:
[clang-repl] Fix error recovery while PTU cleanup (#127467)
[clang][Interpreter] Disable part of lambda test on Windows
The latter commit avoids a test failure seen in Windows builds.
On main, I turned off one of the RUN lines for Windows, but reviewers
on the cherry-pick preferred UNSUPPORTED to disable the whole test.
So I have used UNSUPPORTED in this version for 20.x.
When performing overload resolution during code completion,
clang will allow incomplete substitutions in more places
than would be allowed for valid code, because for completion to work well,
it needs clang to keep going so it can explore the space of possibilities.
Notably, we accept instantiating declarations will null template arguments,
and this works fine, except that when lazily loading serialzied templated
declarations, the template argument hasher assumes null arguments can't
be used.
This patch makes the hasher happily accept that.
Fixes https://github.com/llvm/llvm-project/issues/139019
Since commit 613a077b05b8352a48695be295037306f5fca151, `flang` doesn't
build any longer on Solaris/amd64:
```
flang/lib/Evaluate/intrinsics-library.cpp:225:26:
error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
225 | FolderFactory<F, F{std::acos}>::Create("acos"),
| ^~~~~~~~~
```
That patch led to the version of `quadmath.h` deep inside `/usr/gcc/<N>`
to be found, thus `HAS_QUADMATHLIB` is defined. However, the `struct
HostRuntimeLibrary<__float128, LibraryVersion::Libm>` template is
guarded by `_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600`, while
`clang` only predefines `_XOPEN_SOURCE=500`.
This code dates back to commit 0c1941cb055fcf008e17faa6605969673211bea3
back in 2012. Currently, this is long obsolete and `gcc` prefefines
`_XOPEN_SOURCE=600` instead since GCC 4.6 back in 2011.
This patch follows that.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
(cherry picked from commit e71c8ea3cc73c8f7b0382468f355a254166d3a72)
As reported in #135665, C++20 parenthesis initializer list expressions
are not handled correctly and were causing crashes. This commit attempts
to fix the issue by handing parenthesis initializer lists along side
existing initializer lists.
(cherry picked from commit 5dc9d55eb04d94c01dba0364b51a509f975e542a)
Since P2280R4 Unknown references and pointers was implemented,
HandleLValueBase now has to deal with referneces:
D.MostDerivedType->getAsCXXRecordDecl()
will return a nullptr if D.MostDerivedType is a ReferenceType. The fix
is to use getNonReferenceType() to obtain the Pointee Type if we have a
reference.
Fixes: https://github.com/llvm/llvm-project/issues/139452
(cherry picked from commit 136f2ba2a7bca015ef831c91fb0db5e5e31b7632)
# Conflicts:
# clang/docs/ReleaseNotes.rst
Recently some users reported that they observed large increases of
runtime (up to +600% on some translation units) when they upgraded to a
more recent (slightly patched, internal) clang version. Bisection
revealed that the bulk of this increase was probably caused by my
earlier commit bb27d5e5c6b194a1440b8ac4e5ace68d0ee2a849 ("Don't assume
third iteration in loops").
As I evaluated that earlier commit on several open source project, it
turns out that on average it's runtime-neutral (or slightly helpful: it
reduced the total analysis time by 1.5%) but it can cause runtime spikes
on some code: in particular it more than doubled the time to analyze
`tmux` (one of the smaller test projects).
Further profiling and investigation proved that these spikes were caused
by an _increase of analysis scope_ because there was an heuristic that
placed functions on a "don't inline this" blacklist if they reached the
`-analyzer-max-loop` limit (anywhere, on any one execution path) --
which became significantly rarer when my commit ensured the analyzer no
longer "just assumes" four iterations. (With more inlining significantly
more entry points use up their allocated budgets, which leads to the
increased runtime.)
I feel that this heuristic for the "don't inline" blacklist is
unjustified and arbitrary, because reaching the "retry without inlining"
limit on one path does not imply that inlining the function won't be
valuable on other paths -- so I hope that we can eventually replace it
with more "natural" limits of the analysis scope.
However, the runtime increases are annoying for the users whose project
is affected, so I created this quick workaround commit that approximates
the "don't inline" blacklist effects of ambiguous loops (where the
analyzer doesn't understand the loop condition) without fully reverting
the "Don't assume third iteration" commit (to avoid reintroducing the
false positives that were eliminated by it).
Investigating this issue was a team effort: I'm grateful to Endre Fülöp
(gamesh411) who did the bisection and shared his time measurement setup,
and Gábor Tóthvári (tigbr) who helped me in profiling.
(cherry picked from commit 9600a12f0de233324b559f60997b9c2db153fede)
In my previous attempt (#126913) of fixing the flaky case was on a good
track when I used the begin locations as a stable ordering. However, I
forgot to consider the case when the begin locations are the same among
the Exprs.
In an `EXPENSIVE_CHECKS` build, arrays are randomly shuffled prior to
sorting them. This exposed the flaky behavior much more often basically
breaking the "stability" of the vector - as it should.
Because of this, I had to revert the previous fix attempt in #127034.
To fix this, I use this time `Expr::getID` for a stable ID for an Expr.
Hopefully fixes#126619
Hopefully fixes#126804
(cherry picked from commit f378e52ed3c6f8da4973f97f1ef043c2eb0da721)
The order of operation was slightly incorrect, as we were checking for
incomplete types *before* handling reference types.
Fixes#129397
---------
Co-authored-by: Erich Keane <ekeane@nvidia.com>
FEAT_FP8DOT4 and FEAT_FP8FMA are supported by FUJITSU-MONAKA. These were
previously enabled due to dependencies, but now require explicit
activation due to modifications in the dependencies.
(cherry picked from commit 9d5a5424f0356bd6ee01c751dd6957299783b41b)
This pull request implements mangling for ConstantMatrixType, allowing
matrices to be used on Windows.
Related issues: #53158, #127127
This example code:
```cpp
#include <typeinfo>
#include <stdio.h>
typedef float Matrix4 __attribute__((matrix_type(4, 4)));
int main()
{
printf("%s\n", typeid(Matrix4).name());
}
```
Outputs this:
```
struct __clang::__matrix<float,4,4>
```
(cherry picked from commit f5a30f111dc4ad6422863722eb708059a68a9d5c)
This avoids type suffixes for integer constants when the type can be
inferred from the template parameter, such as the unsigned parameter
of A<1> and A<2> in the added test.
The recently announced IBM z17 processor implements the architecture
already supported as "arch15" in LLVM. This patch adds support for "z17"
as an alternate architecture name for arch15.
This patch also add the scheduler description for the z17 processor,
provided by Jonas Paulsson.
Manual backport of https://github.com/llvm/llvm-project/pull/135254
Check this error for more context
(https://github.com/compiler-research/CppInterOp/actions/runs/14749797085/job/41407625681?pr=491#step:10:531)
This fails with
```
* thread #1, name = 'CppInterOpTests', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x55500356d6d3)
* frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99
frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830
frame #2: 0x00007fffee20917a libclangCppInterOp.so.21.0gitstd::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() + 58
frame #3: 0x00007fffee224796 libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 838
frame #4: 0x00007fffee22494d libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 13
frame #5: 0x00007fffed95ec62 libclangCppInterOp.so.21.0gitclang::IncrementalCUDADeviceParser::~IncrementalCUDADeviceParser() + 98
frame #6: 0x00007fffed9551b6 libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 102
frame #7: 0x00007fffed95598d libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 13
frame #8: 0x00007fffed9181e7 libclangCppInterOp.so.21.0gitcompat::createClangInterpreter(std::vector<char const*, std::allocator<char const*>>&) + 2919
```
Problem :
1) The destructor currently handles no clearance for the DeviceParser
and the DeviceAct. We currently only have this
9764938224/clang/lib/Interpreter/Interpreter.cpp (L416-L419)
2) The ownership for DeviceCI currently is present in
IncrementalCudaDeviceParser. But this should be similar to how the
combination for hostCI, hostAction and hostParser are managed by the
Interpreter. As on master the DeviceAct and DeviceParser are managed by
the Interpreter but not DeviceCI. This is problematic because :
IncrementalParser holds a Sema& which points into the DeviceCI. On
master, DeviceCI is destroyed before the base class ~IncrementalParser()
runs, causing Parser::reset() to access a dangling Sema (and as Sema
holds a reference to Preprocessor which owns PragmaNamespace) we see
this
```
* frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99
frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830
```
(cherry picked from commit 529b6fcb00aabbed17365e5fb3abbc2ae127c967)
925e195 introduced a regression since which we started to accept invalid
trailing commas in many expression lists where they're not allowed by
the grammar. The issue came from the fact that an additional invalid
state - previously handled by ParseExpressionList - was overlooked in
that patch.
Fixes https://github.com/llvm/llvm-project/issues/136254
No release entry because I want to backport it.
(cherry picked from commit c7daab259c3281cf8f649583993bad2536febc02)
**Currently we don't make use of the JIT for the wasm use cases so the
approach using the execution engine won't work in these cases.**
Rather if we use dlopen. We should be able to do the following
(demonstrating through a toy project)
1) Make use of LoadDynamicLibrary through the given implementation
```
extern "C" EMSCRIPTEN_KEEPALIVE int load_library(const char *name) {
auto Err = Interp->LoadDynamicLibrary(name);
if (Err) {
llvm::logAllUnhandledErrors(std::move(Err), llvm::errs(), "load_library error: ");
return -1;
}
return 0;
}
```
2) Add a button to call load_library once the library has been added in
our MEMFS (currently we have symengine built as a SIDE MODULE and we are
loading it)
(cherry picked from commit 8f56394487a4d454be0637667267ad37bd636d0f)
`clang-repl --cuda` was previously crashing with a segmentation fault,
instead of reporting a clean error
```
(base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --cuda
#0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc)
#1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc)
#2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628)
#3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4)
#4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8)
#7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8)
#8 0x000000019ae8c274
Segmentation fault: 11
```
The underlying issue was that the `DeviceCompilerInstance` (used for
device-side CUDA compilation) was never initialized with a `Sema`, which
is required before constructing the `IncrementalCUDADeviceParser`.
89687e6f38/clang/lib/Interpreter/DeviceOffload.cpp (L32)89687e6f38/clang/lib/Interpreter/IncrementalParser.cpp (L31)
Unlike the host-side `CompilerInstance` which runs `ExecuteAction`
inside the Interpreter constructor (thereby setting up Sema), the
device-side CI was passed into the parser uninitialized, leading to an
assertion or crash when accessing its internals.
To fix this, I refactored the `Interpreter::create` method to include an
optional `DeviceCI` parameter. If provided, we know we need to take care
of this instance too. Only then do we construct the
`IncrementalCUDADeviceParser`.
(cherry picked from commit 21fb19f3b5d572f608e959af895d781b9b24fbbd)
Near the ColumnLimit a break could be inserted before a right parens
with BlockIndent without a break after the matching left parens. Avoid
these hanging right parens by disallowing breaks before right parens
unless there was a break after the left parens.
Fixes#103306
(cherry picked from commit b8734797a3f605c4aaa37fcb5007baa273565460)
In ecc7e6ce4, we tried to inspect the `LambdaScopeInfo` on stack to
recover the instantiating lambda captures. However, there was a mismatch
in how we compared the pattern declarations of lambdas: the constraint
instantiation used a tailored `getPatternFunctionDecl()` which is
localized in SemaLambda that finds the very primal template declaration
of a lambda, while `FunctionDecl::getTemplateInstantiationPattern` finds
the latest template pattern of a lambda. This difference causes issues
when lambdas are nested, as we always want the primary template
declaration.
This corrects that by moving `Sema::addInstantiatedCapturesToScope` from
SemaConcept to SemaLambda, allowing it to use the localized version of
`getPatternFunctionDecl`.
It is also worth exploring to coalesce the implementation of
`getPatternFunctionDecl` with
`FunctionDecl::getTemplateInstantiationPattern`. But I’m leaving that
for the future, as I’d like to backport this fix (ecc7e6ce4 made the
issue more visible in clang 20, sorry!), and changing Sema’s ABI would
not be suitable in that regards. Hence, no release note.
Fixes https://github.com/llvm/llvm-project/issues/133719
(cherry picked from commit dcc2182bce3d2ef0e0a991664c51b4b3bfcf7197)
On Windows, GetProcAddress() is the API used to dynamically load
function pointers (similar to dlsym on Linux). This API returns a
function pointer (a typedef named FARPROC), which means that casting
from the call to the eventual correct type is technically a function
type mismatch on the cast. However, because this is idiomatic code on
Windows, we should accept it unless -Wcast-function-type-strict is
passed.
This was brought up in post-commit review feedback on
https://github.com/llvm/llvm-project/pull/86131
According to SDM, they require both VAES/VPCLMULQDQ and AVX10.1 CPUID
bits.
Fixes: #135394
(cherry picked from commit ebba554a3211b0b98d3ae33ba70f9d6ceaab6ad4)
AVX10.2 YMM rounding instructions are removed from latest AVX10 technical paper. Remove all intrinsics from compiler.
AVX10.2 saturate-convert intrinsics are modified to use "s_" in the name. It is a consensus made with GCC folks to avoid future ambiguity.
StringLiteral is used as internal data of EmbedExpr and we directly use
it as an initializer if a single EmbedExpr appears in the initializer
list of a char array. It is fast and convenient, but it is causing
problems when string literal character values are checked because #embed
data values are within a range [0-2^(char width)] but ordinary
StringLiteral is of maybe signed char type.
This PR introduces new kind of StringLiteral to hold binary data coming
from an embedded resource to mitigate these problems. The new kind of
StringLiteral is not assumed to have signed char type. The new kind of
StringLiteral also helps to prevent crashes when trying to find
StringLiteral token locations since these simply do not exist for binary
data.
Fixes https://github.com/llvm/llvm-project/issues/119256
When coroutines are used w/ both -ffat-lto-objects and -flto=thin,
the coroutine passes are not added to the optimization pipelines.
Ensure they are added before ModuleOptimization to generate a
working ELF object.
Fixes#134409.
(cherry picked from commit 268c065eab06b81a0d7256ac62c0865b3781e236)
This reverts commit 8fa0f0efce5fb81eb422e6d7eec74c66dafef4a3.
This change broke assembling for e.g. "armv7s-apple-darwin" triples,
which should enable VFPv4 by default (and did that before this
change), but after this change, only NEON/VFPv3 were available.
This is being fixed properly in latest git main as part of
https://github.com/llvm/llvm-project/pull/130623 (possibly as a
split out change), but any proper fix here seems to have too
much potential surprises for an existing release branch.
While building llvm (clang, lld) against emscripten we see this
[error](https://github.com/emscripten-forge/recipes/actions/runs/13803029307/job/38608794602#step:9:1715)
```
│ │ In file included from $SRC_DIR/llvm/lib/Frontend/OpenACC/ACC.cpp:9:
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:1: error: unknown type name 'LLVM_ABI'
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
│ │ $SRC_DIR/build/include/llvm/Frontend/OpenACC/ACC.h.inc:192:19: error: expected ';' after top level declarator
│ │ 192 | LLVM_ABI Directive getOpenACCDirectiveKind(llvm::StringRef Str);
│ │ | ^
```
Now this was happening because we weren't defining LLVM_ABI correctly when building against emscripten. If you see [llvm/Support/Compiler.h](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Support/Compiler.h#L206-L210), the condition only checked for the platform __WASM__ . Now Emscripten targets WebAssembly but doesn't imply the platform by default so the check isn't complete to define LLVM_ABI.
The successful build after using this patch can be seen [here](https://github.com/emscripten-forge/recipes/actions/runs/13805214092/job/38614585621)
(cherry picked from commit e57cd100ca297cf81854e35cccbf703edddd4aad)
The File ID is incorrectly calculated, resulting in an out-of-bounds
access. The test code is more complex because the File fetching only
happens in specific scenarios.
---------
Co-authored-by: ShaderKeeper <no-reply@shaderkeeper.com>
Co-authored-by: Chuanqi Xu <yedeng.yd@linux.alibaba.com>
(cherry picked from commit cca0f8113e2f9a1bd662c62dd3ff7e1fa197e6b5)
Set the default compilation target to V68 if no Hexagon processor is
specified at the command-line.
Add the elf header changes for v81/v83/v85 architectures.
(cherry picked from commit 759ef5811e2297f2cbe7578f7c118668e3467c6a)
The missing `PT_GNU_EH_FRAME` was causing C++ exception handling test
failures in llvm-test-suite. We should unconditionally add this argument
like the other drivers do.
Discovered-by: Alexey Karyakin <akaryaki@quicinc.com>
Fixes: #129745
(cherry picked from commit 6657769199ad625ea0cb7f7c054d4f6a27806080)
