[SYCL] Improve error message when no compatible device image is found#21749
Open
[SYCL] Improve error message when no compatible device image is found#21749
Conversation
sergey-semenov
approved these changes
Apr 13, 2026
Comment on lines
+1355
to
+1356
| std::string(KernelName) + | ||
| ". The program may not have been compiled for this device."); |
Contributor
There was a problem hiding this comment.
Suggested change
| std::string(KernelName) + | |
| ". The program may not have been compiled for this device."); | |
| std::string(KernelName); |
Nitpick: I'd prefer to keep exception messages on the shorter side and have them be just a basic description of the problem. The last sentence here is likely to be accurate, but I don't think it provides much value, so I would drop it. Might be a matter of personal taste though.
Contributor
Author
There was a problem hiding this comment.
I think you may be right, it seems to be somewhat of a matter of personal taste, but actually I agree. As the old saying goes: "when a program has nothing surprising, interesting or useful to say, it should say nothing".
kweronsx
force-pushed
the
fix/improve-no-compatible-device-error
branch
from
eaa5eb9 to
3019b95
Compare
Maetveis
reviewed
Apr 14, 2026
Maetveis
approved these changes
Apr 14, 2026
Contributor
Maetveis
left a comment
Maetveis
left a comment
There was a problem hiding this comment.
LGTM, with a nit. Thank you!
ProgramManager::getDeviceImage previously threw the same "No kernel named X was found" error for two distinct situations: - the kernel name is genuinely unknown (not registered at all), and - the kernel is known but no binary image in the fat binary targets the device being used at runtime. The second case is typically caused by compiling for a different device architecture than the one executing the binary, which is a common user mistake. Conflating it with an unknown kernel name made the error misleading and hard to diagnose. Introduce a KernelFound flag to distinguish the two paths and emit a dedicated message for the no-compatible-image case.
kweronsx
force-pushed
the
fix/improve-no-compatible-device-error
branch
from
3019b95 to
45e1f6a
Compare
Maetveis
reviewed
Apr 14, 2026
Contributor
|
@intel/llvm-gatekeepers please consider merging |
Add DeviceBinaryProperty::asStringView() to read string-valued properties without reinterpret_cast or manually skipping the 8-byte size header. Use it in getImageTargetLabel() and doesImageTargetMatchDevice() to replace the previous asByteArray()/dropBytes(8)/reinterpret_cast pattern. Extract the comma-separated available-target list building into a new ProgramManager::getKernelTargetList() member function. Update the error message wording from "has no image for the current device. It was compiled for:" to "has no image for the selected device. Its available images target:" — "current" was misleading since the API can be called for an explicitly chosen device, and "compiled for" implied those are the only targets the kernel was ever built for. Update the NoKernelDevice unit test accordingly.
Maetveis
approved these changes
Apr 15, 2026
Contributor
Maetveis
left a comment
Maetveis
left a comment
There was a problem hiding this comment.
LGTM, few more nits, sorry :)
Return std::string_view from getImageTargetLabel() to avoid a heap allocation per image. Add an assert that it is never empty. Add the type-mismatch assert from asCString() to asStringView() as well, since the latter makes the same assumptions about Prop->Type.
Maetveis
reviewed
Apr 15, 2026
Simplify getImageTargetLabel(): rely on the implicit const char* to std::string_view conversion for the DeviceTargetSpec fallback, dropping the now-unnecessary named variable and assert. Rewrite getKernelTargetList() using a first-element-then-rest pattern: initialise the result with the first target, then prepend ", " before each subsequent one. This replaces the previous approach of appending a trailing delimiter after every element and then trimming it, and removes the associated assert on the string length.
Maetveis
approved these changes
Apr 16, 2026
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.
ProgramManager::getDeviceImage previously threw the same "No kernel named X was found" error for two distinct situations:
The second case is typically caused by compiling for a different device architecture than the one executing the binary, which is a common user mistake. Conflating it with an unknown kernel name made the error misleading and hard to diagnose.
Introduce a KernelFound flag to distinguish the two paths and emit a dedicated message for the no-compatible-image case.