aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/Basic
AgeCommit message (Collapse)AuthorFilesLines
2026-02-11[AArch64][clang] Use DenseSet for target feature lookup (NFC) (#180734)Benjamin Maxwell2-4/+37
This resolves a recent AArch64 compile-time regression triggered by #176755, which inadvertently grew the feature lookup `StringSwitch` too large. This patch replaces the `StringSwitch` with a `DenseSet` of target features. This is built with a new `FeatureLookupBuilder` helper, which allows reusing all the existing cases (to avoid unintentionally changing any of them). Compiler-time impact: https://llvm-compile-time-tracker.com/compare.php?from=c9753859d19b07315c5a9a493efaa4df18db84ab&to=cb0684b602d5c741ca99b22bb3bc5f902b7a5a7e&stat=instructions:u
2026-02-10[WebAssembly] Add initial support for compact imports proposal (#176617)Sam Clegg2-0/+13
This change adds initial support to libObject for reading compact imports and support for writing compact imports in the linker. There is minimal testing here since to tools like lllvm-readobj, and obj2yaml don't currently report compact imports any differently. See https://github.com/WebAssembly/compact-import-section
2026-02-10Reland "[NVPTX] Validate user-specified PTX version against SM version" ↵Justin Fargnoli2-2/+7
(#180116) Previous commit message: >Previous commit message: > >> Original commit message: >> >>>When users explicitly specify a PTX version via -mattr=+ptxNN that's insufficient for their target SM, we now emit a fatal error. Previously, we silently upgraded the PTX version to the minimum required for the target SM. >>> >>>When no SM or PTX version is specified, we now use PTX 3.2 (the minimum for the default SM 3.0) instead of PTX 6.0. >> >>The following commits should fix the failures that arose when I previously tried to land this commit: >> >> >>https://github.com/llvm/llvm-project/commit/9fc5fd0ad689eed94f65b1d6d10f9c5642935e68 should address the llvm-nvptx*-nvidia-* build failures: https://github.com/llvm/llvm-project/pull/174834#issuecomment-3742242651 >> >> >>https://github.com/llvm/llvm-project/commit/600514a63760c6730e4cd970d2fcead9c5a897b3 should address the MLIR failures > >The previous commit was reverted with https://github.com/llvm/llvm-project/commit/d23cb79ba497281de050ef609cb91b91058bf323 because the [mlir-nvidia](https://lab.llvm.org/buildbot/#/builders/138/builds/24797) and [mlir-nvidia-gcc7](https://lab.llvm.org/buildbot/#/builders/116/builds/23929) Buildbots were failing. > >Those tests failed because MLIR's default SM was 5.0, which caused NVPTX to target PTX ISA v4.0, which did not support the intrinsics used in the failing tests. > >https://github.com/llvm/llvm-project/commit/243f011577193c99358ccc4142b296d4fa80ea11 should address this by bumping MLIR's default SM to 7.5. Now, using MLIR's new default SM, NVPTX targets the PTX ISA v6.3, which supports the intrinsics used in the failing tests. --- The previous commit was reverted with e9b578a4d77025e18318efedd0f3f3764338d859 [because](https://github.com/llvm/llvm-project/pull/179304#issuecomment-3856301333) the clang driver set the default PTX ISA version to v4.2 when no CUDA installation is found. However, given our patch, we should not set a default; instead, let the LLVM backend select the appropriate PTX ISA version for the target SM.
2026-02-07[X86] AMD Zen 6 Initial enablement (#179150)Ganesh1-0/+4
This patch adds initial support for AMD Zen 6 architecture (znver6): - Added znver6 CPU target recognition in Clang and LLVM - Updated compiler-rt CPU model detection for znver6 - Added znver6 to target parser and host CPU detection - Added znver6 to various optimizer tests znver6 features: FP16, AVXVNNIINT8, AVXNECONVERT, AVXIFMA (without BMM).
2026-02-06[clang]: reflection operator parsing for primitive types (#164692)Nhat Nguyen1-0/+4
(After changing the scope) This PR implements parsing the reflection operator (^^) for primitive types. The goal is to keep the first PR simple. In subsequent PRs, parsing for the remaining requirements will be introduced. This implementation is based on the fork of @katzdm. Class `CXXReflectExpr` is introduced to represent the operand of the reflection operator. For now, in this PR, the type std::meta::info is not implemented yet, so when we construct an AST node CXXReflectExpr, `VoidTy` is used as placeholder type for now. The file `ParseReflect.cpp` is introduced, which for now only has the function `ParseCXXReflectExpression`. It parses the operand of the reflection operator. --------- Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com> Co-authored-by: Hubert Tong <hubert.reinterpretcast@gmail.com> Co-authored-by: Sirraide <aeternalmail@gmail.com> Co-authored-by: Aaron Ballman <aaron@aaronballman.com> Co-authored-by: Erich Keane <ekeane@nvidia.com>
2026-02-06[AMDGPU] Define new target gfx1170 (#180185)Mirko Brkušanin1-0/+1
2026-02-05Revert "Reland "[NVPTX] Validate user-specified PTX version against SM ↵Justin Fargnoli2-7/+2
version"" (#180035) Reverts llvm/llvm-project#179304 due to https://github.com/llvm/llvm-project/pull/179304#issuecomment-3856100622
2026-02-05Reland "[NVPTX] Validate user-specified PTX version against SM version" ↵Justin Fargnoli2-2/+7
(#179304) Previous commit message: > Original commit message: > >>When users explicitly specify a PTX version via -mattr=+ptxNN that's insufficient for their target SM, we now emit a fatal error. Previously, we silently upgraded the PTX version to the minimum required for the target SM. >> >>When no SM or PTX version is specified, we now use PTX 3.2 (the minimum for the default SM 3.0) instead of PTX 6.0. > >The following commits should fix the failures that arose when I previously tried to land this commit: > >https://github.com/llvm/llvm-project/commit/9fc5fd0ad689eed94f65b1d6d10f9c5642935e68 should address the llvm-nvptx*-nvidia-* build failures: https://github.com/llvm/llvm-project/pull/174834#issuecomment-3742242651 > >https://github.com/llvm/llvm-project/commit/600514a63760c6730e4cd970d2fcead9c5a897b3 should address the MLIR failures --- The previous commit was reverted with d23cb79ba497281de050ef609cb91b91058bf323 because the [mlir-nvidia](https://lab.llvm.org/buildbot/#/builders/138/builds/24797) and [mlir-nvidia-gcc7](https://lab.llvm.org/buildbot/#/builders/116/builds/23929) Buildbots were failing. Those tests failed because MLIR's default SM was 5.0, which caused NVPTX to target PTX ISA v4.0, which did not support the intrinsics used in the failing tests. 243f011577193c99358ccc4142b296d4fa80ea11 should address this by bumping MLIR's default SM to 7.5. Now, using MLIR's new default SM, NVPTX targets the PTX ISA v6.3, which supports the intrinsics used in the failing tests.
2026-02-05[Clang][retry 2] Lift HIPSPV onto the new offload driver (#179902)Henry Linjamäki2-6/+8
Update HIPSPV toolchain to support `--offload-new-driver`. Additionally, tailor llvm-spirv invocation for [chipStar](github.com/CHIP-SPV/chipStar) via `spirv64-*-chipstar` offload triple. AFAICT, all the relevant test failures in the previous PR (#178664) came from tests involving `-Xoffload-compiler ‘-###’` in their RUN directives. I have reworked those tests in this PR.
2026-02-05Reland "[clang][RISCV] Add big-endian RISC-V target support" (#177939)Djordje Todorovic2-0/+4
The problem was using the `--rtlib=platform` without `--unwindlib=platform` conflicts the default unwindlib with the Fuchsia's configuration, and that is why the test failed. Orignal PR: https://github.com/llvm/llvm-project/pull/165599 The fail was reported at: https://github.com/llvm/llvm-project/pull/165599#issuecomment-3751750804 Co-authored-by: Djordje Todorovic <djordje.todorovic@syrmia.com>
2026-02-02[X86][APX] Disable PP2/PPX generation on Windows (#178122)Phoebe Wang1-2/+8
The PUSH2/POP2/PPX instructions for APX require updates to the Microsoft Windows OS x64 calling convention documented at https://learn.microsoft.com/en-us/cpp/build/exception-handling-x64?view=msvc-170 due to lack of suitable unwinder opcodes that can support APX PUSH2/POP2/PPX. The PR request disables this support by default for code robustness; workloads that choose to explicitly enable this support can change the default behavior by explicitly specifying the flag options that enable this support e.g. for experimentation or code paths that do not need unwinder support.
2026-01-30Revert "[Clang][retry] Lift HIPSPV onto the new offload driver" (#178946)Joseph Huber2-8/+6
Reverts llvm/llvm-project#178664 Failing: https://ci.swift.org/job/llvm.org/job/clang-stage2-cmake-RgSan/1328/testReport/junit/Clang/Driver/hipspv_pass_plugin_hip/ https://github.com/llvm/llvm-project/actions/runs/21525522898/job/62027988341?pr=178931 https://github.com/llvm/llvm-project/actions/runs/21525522898/job/62027988341?pr=178931
2026-01-30[Clang][retry] Lift HIPSPV onto the new offload driver (#178664)Henry Linjamäki2-6/+8
Update HIPSPV toolchain to support --offload-new-driver. Additionally, tailor llvm-spirv invocation for [chipStar](https://github.com/CHIP-SPV/chipStar) via `spirv64-*-chipstar` offload triple. The previous PR (#168043) had CI failures that were not caught early. This one attempts to address them.
2026-01-29[clang][driver][darwin] Prefer DarwinSDKInfo for platform identification and ↵Ian Anderson1-1/+5
compatibility over the -isysroot path (#176541) Using the file system path to identify the SDK platform, and determine which platforms the SDK supports, is unreliable. In particular, the SDK's file name prefix is usually significant, and dropping it usually gives incorrect results. Instead, use information from SDKinfo to positively identify its platform/environment, and to identify which triples are compatible.
2026-01-29Revert "[RISCV] Support RISCV BitInt larger than 128 (#175515)" (#178311)Craig Topper1-4/+0
This reverts commit e3156c531da5aa4ec604605ed4e19638879d773c. We need to resolve a crash on trunk and LLVM 22. Reverting makes it easier to backport. Fixes #176637.
2026-01-29Revert "[Clang] Lift HIPSPV onto the new offload driver (#168043)"Joseph Huber2-8/+6
This reverts commit 9ae6d8f565515a0199b18d6f156b1a41f328af1a. This reverts commit d2e18bebe0b95d09ef8d0ac2ba0aa8d0e129be54.
2026-01-29[Clang] Lift HIPSPV onto the new offload driver (#168043)Henry Linjamäki2-6/+8
Update HIPSPV toolchain to support `--offload-new-driver`. Additionally, tailor `llvm-spirv` invocation for [chipStar](https://github.com/CHIP-SPV/chipStar) via `spirv64-*-chipstar` offload triple. Depends on one commit from #170467 and one from #170655. --------- Co-authored-by: Henry Linjamäki <henry.mikael.linjamaki@intel.com> Co-authored-by: Joseph Huber <huberjn@outlook.com>
2026-01-28[Mips] Add r5900 (PlayStation 2 Emotion Engine) CPU support (#176666)Rick Gaiser1-1/+3
This PR adds basic support for the MIPS R5900 CPU, the Emotion Engine processor used in the PlayStation 2. **LLVM changes:** - Add r5900 CPU definition (with soft float support for now) - Disable instructions not supported by r5900 (64-bit multiply/divide, LL/SC atomics, COP3) - Add r5900 specific short loop delay slot fix (hardware errata workaround) - Set ISA extension `AFL_EXT_5900` in ELF flags for proper ABI identification **Clang changes:** - Add r5900 as a valid CPU target for `-mcpu=r5900` - Add r5900 to CPU test coverage
2026-01-27[clang][driver][darwin] Switch back to using CanonicalName to identify the ↵Ian Anderson1-50/+56
SDK instead of SupportedTargets (#178115) The SDK's SupportedTarget for its CanonicalName doesn't necessarily have an LLVMTargetTripleSys/LLVMTargetTripleEnvironment that matches the CanonicalName. e.g. sometimes new SDKs use arm64-apple-ios1.0 during bringup, but their CanonicalName is set to the new platform. Go back to using CanonicalName to identify the SDK as a Triple::OSType, and expose the Triple::EnvironmentType used to build the SDKPlatformInfo when SupportedTargets isn't present.
2026-01-26macCatalyst: add SDKSettings.json as a dependency file if its potentially ↵Ian Anderson1-3/+5
needed by the compiler (#178077) Co-authored-by: Alex Lorenz <arphaman@gmail.com>
2026-01-26Revert "macCatalyst: add SDKSettings.json as a dependency file if its ↵Ian Anderson1-5/+3
potentially needed by the compiler (#177748)" (#178075) This reverts commit 7b917b9a08e2dac495fd9e83dc8cf152c8df6fde.
2026-01-26macCatalyst: add SDKSettings.json as a dependency file if its potentially ↵Ian Anderson1-3/+5
needed by the compiler (#177748) Co-authored-by: Alex Lorenz <arphaman@gmail.com>
2026-01-26Revert "Reland "[NVPTX] Validate user-specified PTX version against SM ↵Justin Fargnoli2-7/+2
version"" (#178046) Reverts llvm/llvm-project#177459 `mlir-nvidia` and `mlir-nvidia-gcc7` Buildbots are failing. The blamelist is small and likely because of my change. Preemptively reverting.
2026-01-26Reland "[NVPTX] Validate user-specified PTX version against SM version" ↵Justin Fargnoli2-2/+7
(#177459) Original commit message: > When users explicitly specify a PTX version via -mattr=+ptxNN that's insufficient for their target SM, we now emit a fatal error. Previously, we silently upgraded the PTX version to the minimum required for the target SM. > >When no SM or PTX version is specified, we now use PTX 3.2 (the minimum for the default SM 3.0) instead of PTX 6.0. --- The following commits should fix the failures that arose when I previously tried to land this commit: - 9fc5fd0ad689eed94f65b1d6d10f9c5642935e68 should address the `llvm-nvptx*-nvidia-*` build failures: https://github.com/llvm/llvm-project/pull/174834#issuecomment-3742242651 - 600514a63760c6730e4cd970d2fcead9c5a897b3 should address the MLIR failures
2026-01-22[AMDGPU] Define gfx1310 target with ELF number 0x50 (#177355)Mariusz Sikora1-0/+1
For now this is identical to gfx1250. --------- Co-authored-by: Jay Foad <jay.foad@amd.com>
2026-01-21[Clang][WebAssembly] Fix crash when using __funcref in C++ code (#176237)Paulo Matos1-0/+1
Enable address space map mangling for the WebAssembly target. This fixes a crash in the Itanium name mangler when trying to mangle types with the wasm_funcref address space qualifier in C++ mode. Fixes #176154
2026-01-21[PowerPC] Add Support for BCDSHIFT, BCDSHIFTR, BCDTRUNC, BCDUTRUNC, and ↵Aditi Medhane1-0/+7
BCDUSHIFT instruction support (#154715) Support the following BCD format conversion builtins for PowerPC. - `__builtin_bcdshift` – Shifts a packed decimal value by a specified number of decimal digits. - `__builtin_bcdshiftround` – Shifts a packed decimal value by a specified number of decimal digits, with rounding applied. - `__builtin_bcdtruncate` –Truncates a packed decimal value to a specified number of digits. - `__builtin_bcdunsignedtruncate` – Truncates a packed decimal value and returns the result as an unsigned packed decimal. - `__builtin_bcdunsignedshift` – Shifts an unsigned packed decimal value by a specified number of digits. > Note: This built-in functions are valid only when all following conditions are met: > -qarch is set to utilize POWER9 technology. > The bcd.h file is included. ## Prototypes ```c vector unsigned char __builtin_bcdshift(vector unsigned char, int, unsigned char); vector unsigned char __builtin_bcdshiftround(vector unsigned char, int, unsigned char); vector unsigned char __builtin_bcdtruncate(vector unsigned char, int, unsigned char); vector unsigned char __builtin_bcdunsignedtruncate(vector unsigned char, int); vector unsigned char __builtin_bcdunsignedshift(vector unsigned char, int); ``` ---------
2026-01-21[Clang][AArch64] Add ACLE macros to support Armv9.6 (#176755)CarolineConcatto2-0/+63
This patch add the macros for Armv9.6 according to the ACLE[1] [1]https://github.com/ARM-software/acle/blob/main/main/acle.md --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
2026-01-20Reapply "[C++20][Modules] Implement P1857R3 Modules Dependency Discovery" ↵yronglin2-2/+26
(#173130)" (#173789) The patch reapply https://github.com/llvm/llvm-project/pull/173130. This patch implement the following papers: [P1857R3 Modules Dependency Discovery](https://wg21.link/p1857r3). [P3034R1 Module Declarations Shouldn’t be Macros](https://wg21.link/P3034R1). [CWG2947](https://cplusplus.github.io/CWG/issues/2947.html). At the start of phase 4 an import or module token is treated as starting a directive and are converted to their respective keywords iff: - After skipping horizontal whitespace are - at the start of a logical line, or - preceded by an export at the start of the logical line. - Are followed by an identifier pp token (before macro expansion), or - <, ", or : (but not ::) pp tokens for import, or - ; for module Otherwise the token is treated as an identifier. Additionally: - The entire import or module directive (including the closing ;) must be on a single logical line and for module must not come from an #include. - The expansion of macros must not result in an import or module directive introducer that was not there prior to macro expansion. - A module directive may only appear as the first preprocessing tokens in a file (excluding the global module fragment.) - Preprocessor conditionals shall not span a module declaration. After this patch, we handle C++ module-import and module-declaration as a real pp-directive in preprocessor. Additionally, we refactor module name lexing, remove the complex state machine and read full module name during module/import directive handling. Possibly we can introduce a tok::annot_module_name token in the future, avoid duplicatly parsing module name in both preprocessor and parser, but it's makes error recovery much diffcult(eg. import a; import b; in same line). This patch also introduce 2 new keyword `__preprocessed_module` and `__preprocessed_import`. These 2 keyword was generated during `-E` mode. This is useful to avoid confusion with `module` and `import` keyword in preprocessed output: ```cpp export module m; struct import {}; #define EMPTY EMPTY import foo; ``` Fixes https://github.com/llvm/llvm-project/issues/54047 The previous patch has an use-after-free issue in Lexer::LexTokenInternal function. Since C++20, the `export`, `import` and `module` identifiers may be an introducer of a C++ module declaration/importing directive, and the directive will handled in `LexIdentifierContinue`. Unfortunately, the EOF may be encountered in `LexIdentifierContinue` and `CurLexer` might be destructed in `HandleEndOfFile`, If the code after `LexIdentifierContinue` try to access `LangOps` or other class members in this Lexer, it will hit undefined behavior. This patch also fix the use-after-free issue in Lexer by introduce a mechanism to delay the destruction of `CurLexer` in `Preprocessor` class. --------- Signed-off-by: yronglin <yronglin777@gmail.com>
2026-01-17[clang][LoongArch] Add support for LoongArch32 (#172619)hev2-2/+18
This patch adds support for LoongArch32, as introduced in la-toolchain-conventions v1.2. Co-authored-by: Sun Haiyong <sunhaiyong@zdbr.net> Link: https://github.com/loongson/la-toolchain-conventions/releases/tag/releases%2Fv1.2 Link: https://gcc.gnu.org/pipermail/gcc-patches/2025-December/703312.html
2026-01-16[OpenMP][Clang] Parsing/Sema support for ↵Abhinav Gaba1-2/+20
`use_device_ptr(fb_preserve/fb_nullify)`. (2/4) (#170578) Depends on #169603. This is the `use_device_ptr` counterpart of #168905. With OpenMP 6.1, a `fallback` modifier can be specified on the `use_device_ptr` clause to control the behavior when a pointer lookup fails, i.e. there is no device pointer to translate into. The default is `fb_preserve` (i.e. retain the original pointer), while `fb_nullify` means: use `nullptr` as the translated pointer. Dependent PR: #173930.
2026-01-14Revert "[clang][RISCV] Add big-endian RISC-V target support" (#176039)Djordje Todorovic2-4/+0
Reverts llvm/llvm-project#165599
2026-01-14[clang][RISCV] Add big-endian RISC-V target support (#165599)Djordje Todorovic2-0/+4
We proceeded with frontend/clang changes, until we figure out how ABI for BE should look like. Once it is final, we will proceed with codegen changes. In this patch several things addressed: - Define riscv32be/riscv64be target triples - Set correct data layout for BE targets - Handle BE-specific ABI details - Emit warning for BE case since it is still experimental
2026-01-14[AMDGPU] Programmatically port old `.def` clang builtins to `.td` (#175873)Joseph Huber1-12/+10
Summary: This PR ports the old `.def` builtins to the new Tablegen interface. This required a few changes in the handler, namely there is a real meaning to `AS(0)` right now, not just in SPIR-V but when the type parser expects it. The conversion here should be 1-to-1. Some more work could be done to reduce the amount of repetition by grouping all the instructions together, I'll leave that up to whether or not anyone cares. This was done with a hastily made Python script that likely will not work for the other files, but will successfully update this PR. Putting here in case someone wants to use it. https://gist.github.com/jhuber6/d524c65c0da3adae5afd2ad160589537
2026-01-13Fix typos and spelling errors across codebase (#156270)Austin Jiang1-1/+1
Corrected various spelling mistakes such as 'occurred', 'receiver', 'initialized', 'length', and others in comments, variable names, function names, and documentation throughout the project. These changes improve code readability and maintain consistency in naming and documentation. Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
2026-01-13Revert "[NVPTX] Validate user-specified PTX version against SM version" ↵Mehdi Amini2-7/+2
(#175760) Reverts llvm/llvm-project#174834 Bots are broken.
2026-01-13[RISCV] Support RISCV BitInt larger than 128 (#175515)Piyou Chen1-0/+4
fa57074d146925a303263905af415cc78f58f353 constraint the RISCV BitInt with 128 bits. It is due to fp <-> int convension will crash in backend. (https://godbolt.org/z/9o1qr4rje) This patch enable larger than 128 bits BitInt type by `setMaxLargeFPConvertBitWidthSupported`.
2026-01-13[Clang][AMDGPU] Get correct nullptr value for AS3 and AS5 (#175610)Shilei Tian1-5/+7
2026-01-12[CUDA] Implement __CUDA_ARCH_LIST__ macro and refactor architecture helpers ↵Artem Belevich2-145/+91
(#175260) Closes #172937 https://docs.nvidia.com/cuda/cuda-compiler-driver-nvcc/#virtual-architecture-macros > The architecture list macro `__CUDA_ARCH_LIST__` is a list of comma-separated `__CUDA_ARCH__` values for each of the virtual architectures specified in the compiler invocation. The list is sorted in numerically ascending order. Note that unlike NVCC which defines the macro for all C/C++/CUDA compilations done with nvcc, clang defines the macro *only* for CUDA compilations.
2026-01-12[NVPTX] Validate user-specified PTX version against SM version (#174834)Justin Fargnoli2-2/+7
When users explicitly specify a PTX version via `-mattr=+ptxNN` that's insufficient for their target SM, we now emit a fatal error. Previously, we silently upgraded the PTX version to the minimum required for the target SM. When no SM or PTX version is specified, we now use PTX 3.2 (the minimum for the default SM 3.0) instead of PTX 6.0.
2026-01-12[AArch64] Add support for range prefetch intrinsic (#170490)Kerry McLaughlin1-0/+3
This patch adds support in Clang for the RPRFM instruction, by adding the following intrinsics: ``` void __pldx_range(unsigned int *access_kind*, unsigned int retention_policy, signed int length*, unsigned int count, signed int stride, size_t reuse distance, void const *addr); void __pld_range(unsigned int access_kind*, unsigned int retention_policy, uint64_t metadata, void const *addr); ``` The `__ARM_PREFETCH_RANGE` macro can be used to test whether these intrinsics are implemented. If the RPRFM instruction is not available, this instruction is a NOP. This implements the following ACLE proposal: https://github.com/ARM-software/acle/pull/423
2026-01-12[SPIR-V] Do not allow AS(2) to convert to generic (#175275)Joseph Huber1-2/+3
Summary: The original logic permitted this, while it's not permitted by the standard. --------- Co-authored-by: Dmitry Sidorov <18708689+MrSidims@users.noreply.github.com>
2026-01-10Rename wasm32-wasi to wasm32-wasip1. (#165345)Dan Gohman2-10/+55
This adds code to recognize "wasm32-wasip1", "wasm32-wasip2", and "wasm32-wasip3" as explicit targets, and adds a deprecation warning when the "wasm32-wasi" target is used, pointing users to the "wasm32-wasip1" target. Fixes #165344. I'm filing this as a draft PR for now, as I've only just now proposed to make this change in #165344.
2026-01-09[SPIR-V] Permit implicit conversion to generic AS (#175109)Joseph Huber1-0/+11
Summary: We rely on this in most places we work with address spaces. This allows target address spaces to implicity convert to generic ones. I actually have no clue if this is valid or correct with SPIR-V, hoping someone with more target / backend knowledge can chime in. --------- Co-authored-by: Matt Arsenault <arsenm2@gmail.com>
2026-01-08[clang][driver][darwin] Report bad SDKSettings as a fatal error rather than ↵Ian Anderson1-1/+3
unreachable (#175073) Fatal error is more appropriate than unreachable when the SDKSettings is not in a recognized form (encountered in a few tests with incomplete SDKSettings.json).
2026-01-05[clang][driver][darwin] Base the platform prefix on the SDK, not the target ↵Ian Anderson1-22/+99
(#171970) The search path prefix is really a property of the SDK, and not the target triple. The target is just being used as a proxy for the SDK. That's problematic when the SDK being used doesn't match the target assumption, and the prefix should be taken from the SDK rather than hard coded. Parse the SupportedTargets, which is what holds the platform prefix, in DarwinSDKInfo. SupportedTargets contains an entry for the SDK's canonical name, and that entry holds a valid OS value so use that instead of the hard coded map. Include the environment which is also relevant in some situations, and the vendor and object format in case they're useful later. Skip architectures because they typically aren't used for doing platform matching.
2025-12-25Revert "Reapply "[C++20][Modules] Implement P1857R3 Modules Dependency ↵yronglin2-26/+2
Discovery" (#173130)" (#173549) This reverts commit 0d1c396ce8178baf05f277b16bf41b8a6b847d6d. Co-authored-by: Yihan Wang <yihwang@nvidia.com>
2025-12-25Reapply "[C++20][Modules] Implement P1857R3 Modules Dependency Discovery" ↵yronglin2-2/+26
(#173130) This PR reapply https://github.com/llvm/llvm-project/pull/107168. --------- Signed-off-by: Wang, Yihan <yronglin777@gmail.com> Signed-off-by: yronglin <yronglin777@gmail.com>
2025-12-19Revert "[C++20][Modules] Implement P1857R3 Modules Dependency Discovery" ↵Paul Kirth2-26/+2
(#173118) Reverts llvm/llvm-project#107168 This patch broke on bots: - https://lab.llvm.org/buildbot/#/builders/190/builds/33105 - https://lab.llvm.org/buildbot/#/builders/94/builds/13727 - https://lab.llvm.org/buildbot/#/builders/169/builds/18192 and on mac-aarch64 builds. see https://github.com/llvm/llvm-project/pull/107168#issuecomment-3675990781
2025-12-19[C++20][Modules] Implement P1857R3 Modules Dependency Discovery (#107168)yronglin2-2/+26
This PR implement the following papers: [P1857R3 Modules Dependency Discovery](https://wg21.link/p1857r3). [P3034R1 Module Declarations Shouldn’t be Macros](https://wg21.link/P3034R1). [CWG2947](https://cplusplus.github.io/CWG/issues/2947.html). At the start of phase 4 an import or module token is treated as starting a directive and are converted to their respective keywords iff: - After skipping horizontal whitespace are - at the start of a logical line, or - preceded by an export at the start of the logical line. - Are followed by an identifier pp token (before macro expansion), or - <, ", or : (but not ::) pp tokens for import, or - ; for module Otherwise the token is treated as an identifier. Additionally: - The entire import or module directive (including the closing ;) must be on a single logical line and for module must not come from an #include. - The expansion of macros must not result in an import or module directive introducer that was not there prior to macro expansion. - A module directive may only appear as the first preprocessing tokens in a file (excluding the global module fragment.) - Preprocessor conditionals shall not span a module declaration. After this patch, we handle C++ module-import and module-declaration as a real pp-directive in preprocessor. Additionally, we refactor module name lexing, remove the complex state machine and read full module name during module/import directive handling. Possibly we can introduce a tok::annot_module_name token in the future, avoid duplicatly parsing module name in both preprocessor and parser, but it's makes error recovery much diffcult(eg. import a; import b; in same line). This patch also introduce 2 new keyword `__preprocessed_module` and `__preprocessed_import`. These 2 keyword was generated during `-E` mode. This is useful to avoid confusion with `module` and `import` keyword in preprocessed output: ```cpp export module m; struct import {}; #define EMPTY EMPTY import foo; ``` Fixes https://github.com/llvm/llvm-project/issues/54047 --------- Signed-off-by: yronglin <yronglin777@gmail.com> Signed-off-by: Wang, Yihan <yronglin777@gmail.com>
generated by cgit v1.2.3 (git 2.39.1) at 2026-05-16 10:37:39 +0000