Update 1.10.2605 preview release to main#8457
Merged
V-FEXrt merged 20 commits intoMay 18, 2026
Merged
Conversation
Fixes microsoft#8306. ## Summary Building DXC with newer Apple toolchains fails in `include/llvm/ADT/StringRef.h` because libc++ now rejects user specializations of certain standard library traits. DXC currently specializes: - `std::is_nothrow_constructible<std::string, llvm::StringRef>` - `std::is_nothrow_constructible<std::string, llvm::StringRef &>` - `std::is_nothrow_constructible<std::string, const llvm::StringRef &>` On Xcode 26.4 / Apple clang 21 / libc++, that now produces an error like: > `is_nothrow_constructible` cannot be specialized: Users are not allowed to specialize this standard library entity ## What this changes This patch keeps the existing HLSL workaround for non-libc++ standard libraries, but disables those `std::is_nothrow_constructible` specializations when building against libc++: ```cpp #if !defined(_LIBCPP_VERSION) ... #endif ``` Why this fixes the issue The failure is caused by the specializations themselves, not by any runtime behavior in StringRef. For libc++: - the specializations are now ill-formed and rejected at parse time - libc++ already computes std::is_nothrow_constructible<std::string, llvm::StringRef> correctly without the workaround So the fix is to stop declaring the forbidden specialization on libc++, while preserving the existing behavior everywhere else. Why I chose this approach I looked at the HLSL-specific block in StringRef.h and tested the current Apple libc++ behavior directly. Without the manual specialization, libc++ still reports the relevant is_nothrow_constructible cases as false, which matches the intent of the original workaround. That made this the narrowest safe fix: - it resolves the Xcode/libc++ build break in microsoft#8306 - it does not change runtime code generation or ABI - it preserves the original workaround for non-libc++ environments where it may still be needed Validation I verified: - the original header fails to compile with current Xcode/libc++ - after this change, the header compiles cleanly - on libc++, the relevant std::is_nothrow_constructible instantiations still evaluate to false
Tests are updated to match the output of a new optimization in spirv-tools.
…crosoft#8405) Add `vk::SampledTexture` to the release notes.
The removed function was getting or creating a counter. But the called function (called *get* counter) was also creating the counter with the same pattern if no counter was found. This essentially meant the parent create code was dead code.
Fixes build break introduced by ec9d97a (microsoft#8365), which referenced hlsl::GetVKBufferPointerAlignment and m_vkBufferPointerTemplateDecl unconditionally. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
No PR build exercised the SPIR-V-disabled configuration, so breakage of that build could land unnoticed. Add a Windows Release job that builds and tests with `ENABLE_SPIRV_CODEGEN` off to guard against this. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`volatile` is not a valid keyword in HLSL, it is meaningless in this language. However, it comes as a result of the fact that HLSL is build on a C/C++ compiler, so there are some C++ artifacts that are part of the language. This scenario goes into more detail: llvm/wg-hlsl#300 Though DXC currently does and seems to always have compiled with the volatile keyword, this is not sensible and should be disallowed. Fixes microsoft#8391 Assisted by: Github Copilot --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
There is a logic to create counter variables, and find them from a source expression. For return statements, we were first looking for the referenced counter before dealing with the RHS of the expression: the call. The fact that it worked so far was just luck: - if the function decl was handled/seen before the return statement, the counter variable association was handled. But in case of a direct return, this was not the case. Fixes microsoft#8215
This patch fixes 2 instances of internal issues; C6214: Cast between semantically different integer types. Fixes internal bugs: 61940839 and 61940838 --------- Co-authored-by: Deric C. <cheung.deric@gmail.com>
Update spirv-tools to the latest release candidate.
…ype (microsoft#8394) If the `Bias` vector type/interpretation on `MultiplyAdd` differs from the output vector type, convert it first to the output vector type before passing it into the `__builtin_LinAlg_MatrixVectorMultiplyAdd` built-in function (which gets translated to `dx.op.linAlgMatVecMulAdd` op). The bias vector interpretation is always going to be the same as the output vector interpretation on the call. To accommodate this, each `MultiplyAdd` now has two SFINAE-constrained variants: 1. If the bias interpretation matches the output vector interpretation, no conversion is necessary and the function calls built-in/dxil op directly. 2. If types don't match, the bias vector is first converted to the output vector type before passing it into the built-in/dxil op. Adds `hlsl::__detail::TypeTraits` struct to enable mapping of HLSL scalar types to component type enum values. Fixes microsoft#8390
…n LinAlg exec tests (microsoft#8420) Float fill values streamed into compiler defines (e.g. -DFILL_VALUE=42) were losing their decimal point, causing HLSL to interpret them as integers. Add std::showpoint to all stringstreams that format float values into -D defines so they always emit a decimal point. Fixed this in: SplatStore_Wave_16x16_F16 MatMatMul_Wave_16x16x16_F16 MatMatMulAccum_Wave_16x16x16_F16 MatAccum_Wave_16x16_F16 StoreMemory_Wave_16x16_F16 AccumulateMemory_Wave_16x16_F16 Also suffix fill value literals with F (e.g. -DFILL_VALUE=42.0000F) to ensure they are interpreted as float rather than unsuffixed floating point literals, which lack a concrete representation outside HLSL 202x and may cause clang codegen to select double. Also fixes the computation of the flatenned coordinate in ElementAccess_Wave_16x16_F16.
This change adds a policy for use of AI tools when generating content to be contributed to this repo. --------- Co-authored-by: Deric C. <cheung.deric@gmail.com>
…8441) Fixes microsoft#8433 The validator was rejecting `%dx.types.LinAlgMatrix***` types causing debug build to be rejected. This PR notes that type as an allowed type
…osoft#8444) SwitchLookupTable built bitmap APInts of width `TableSize * ResultBitWidth`, producing non-standard integer widths (i9, i17, i26, i33, i40, ...) that DXIL validation rejects - DXIL only allows i1/i8/i16/i32/i64. Round the bitmap width up to a legal width, and cap the optimization at 32 bits to avoid silently promoting to i64 (which would set the Int64Ops shader flag and add a 64-bit-integer capability requirement the source shader did not have). Wider tables fall back to the array path, or - for i1 results - preserve the original switch. Closes microsoft#8421 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
…oft#8442) This broke for -fcgl when adding resource type annotations in DXIL 1.8. It broke because the dx.types.ResourceProperties type was created by the DxilModule DxilOperations class (hlsl::OP), and the code tried to get this class from the DxilModule, which was nullptr because it was serializing an HLModule, not a DxilModule. The fix moves dx.types.ResourceProperties type creation to hlsl::resource_helper, which is where it seems to fit best. The local member and accessor in hlsl::OP is left as this will cache the type, as it did before, instead of looking it up by name frequently for each dxil op. Only the initialization of the hlsl::OP member is changed to use the resource_helper function instead. Fixes microsoft#8440
This is a refactoring to move the rejection of pointer and reference types into Sema rather than rejecting it during parsing. This has a few consequences and benefits. The consequence as seen in the changes to the cpp-errors tests are that we don't see pointer use errors in cases where a parser error prevents sema code from executing (as seen in operator cases). The benefit is that this also intercepts pointer and reference types that are deduced (via templates, auto or decltype).
Implements VectorAccumulateToDescriptor builtin and updates the header implementation. Fixes microsoft#8416 Co-Authored-By: @pow2clk --------- Co-authored-by: Tex Riddell <texr@microsoft.com>
tex3d
approved these changes
May 18, 2026
damyanp
approved these changes
May 18, 2026
V-FEXrt
merged commit e695785
into
microsoft:release-preview-1.10.2605
13 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
13 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updates the release branch for 1.10.2605 preview to
main. Part of the release activities for #8455