[Driver][SYCL] Fix -check-section triple matching after f8cb6be61b99#22544
Merged
wenju-he merged 1 commit intoJul 7, 2026
Conversation
f8cb6be switched OffloadBundler::ConstructJob's host-triple from CurTC->getTriple() to CurTC->ComputeEffectiveClangTriple(), which for MSVCToolChain injects the detected MSVC toolset version into the environment field (e.g. host-x86_64-pc-windows-msvc19.29.30159). That broke clang-offload-bundler -check-section, which compared the bundle's stored triple against the -targets= string via raw string equality, causing `clang-offload-bundler -check-section -targets=host-x86_64-pc-windows-msvc` to fail to find the host bundle. This PR aligns CheckBundledSection with the existing -unbundle path: both now go through OffloadTargetInfo/isCodeObjectCompatible(), which already relies on Triple::isCompatibleWith() and ignores the environment- version component. This fixes the root inconsistency between -check-section and -unbundle target matching. Test's 6-component change is due to a pre-existing upstream behavior: OffloadTargetInfo's constructor silently drops an unrecognized trailing target-id component (i.e. "-b") as `TargetID = ""`. `-c`/`-d`/`-e` suffixed spir64/spir64_gen/spir64_x86_64 targets in the test still match their un-suffixed counterparts because those go through a different code path (target strings with fewer than 5 dash-separated components) where the bogus suffix lands in llvm::Triple's vendor/ environment field instead; Triple::isCompatibleWith compares those fields as enums, and any unrecognized string collapses to the same Unknown enum value, so it still matches. These are pre-existing behaviors, out of scope for this change. CMPLRLLVM-76621 Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
mdtoguchi
approved these changes
Jul 7, 2026
wenju-he
deleted the
fix-clang-offload-bundler-bc-archive-support-win-old-model.cpp
branch
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
3 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.
f8cb6be switched OffloadBundler::ConstructJob's host-triple from CurTC->getTriple() to CurTC->ComputeEffectiveClangTriple(), which for MSVCToolChain injects the detected MSVC toolset version into the environment field (e.g. host-x86_64-pc-windows-msvc19.29.30159).
That broke clang-offload-bundler -check-section, which compared the bundle's stored triple against the -targets= string via raw string equality, causing
clang-offload-bundler -check-section -targets=host-x86_64-pc-windows-msvcto fail to find the host bundle.This PR aligns CheckBundledSection with the existing -unbundle path: both now go through OffloadTargetInfo/isCodeObjectCompatible(), which already relies on Triple::isCompatibleWith() and ignores the environment- version component. This fixes the root inconsistency between -check-section and -unbundle target matching.
Test's 6-component change is due to a pre-existing upstream behavior: OffloadTargetInfo's constructor silently drops an unrecognized trailing target-id component (i.e. "-b") as
TargetID = "".-c/-d/-esuffixed spir64/spir64_gen/spir64_x86_64 targets in the test still match their un-suffixed counterparts because those go through a different code path (target strings with fewer than 5 dash-separated components) where the bogus suffix lands in llvm::Triple's vendor/ environment field instead; Triple::isCompatibleWith compares those fields as enums, and any unrecognized string collapses to the same Unknown enum value, so it still matches.These are pre-existing behaviors, out of scope for this change.
CMPLRLLVM-76621