Created using spr 1.3.5-bogner
This adds the following instruction formats from the Xqci Spec: - QC.EAI - QC.EI - QC.EB - QC.EJ - QC.ES The update to the THead test is because the largest number of operands for a valid instruction has been bumped by this change. This reverts commit 68fb7a5a1d203dde7badf67031bdd9eb650eef5d. This relands commit 0cfabd37df9940346f3bf8a4d74c19e1f48a00e9.
The motivation for this patch is that in Statistics.cpp we [check to see if the module symfile is loaded](https://github.com/llvm/llvm-project/blob/990a086d9da0bc2fd53a6a4c95ecbbe23a297a83/lldb/source/Target/Statistics.cpp#L353C60-L353C75) to calculate how much debug info has been loaded. I have an external utility that only wants to look at the loaded debug info, which isn't exposed by the SBAPI.
This reapplies 5ffd9bdb50b57 (#133545) with fixes. The BUILD_SHARED_LIBS=ON build was fixed by adding missing LLVM dependencies to the InterpTests binary in unittests/AST/ByteCode/CMakeLists.txt .
This was disabled due to flakiness but I'm currently unable to reproduce. I'm nervous the original issue still exists. However, I downgraded the tripped assert in 8c18c25b1b22ea710edb40a4f167a6a8bfe6ff9d to a warning since the same assert can trigger for illegitimate reasons. Fixes #64157
debugserver isn't saving and restoring the SVE/SME register state around inferior function calls. Making arbitrary function calls while in Streaming SVE mode is generally a poor idea because a NEON instruction can be hit and crash the expression execution, which is how I missed this, but they should be handled correctly if the user knows it is safe to do. rdar://146886210
KnownBits passed to computeKnownBitsFromRangeMetadata must have the same bit width as the range metadata bit width. Otherwise the calculated results will be incorrect. --------- Signed-off-by: John Lu <John.Lu@amd.com>
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
When the list is large, using `llvm::is_contained` is of higher performance than a sequence of comparisons. When the list is small, the `llvm::is_contained` can be inlined and unrolled, which has the same effect as using a sequence of comparisons. And the generated code is more readable.
Fix #133873