You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In SYCL 1.2.1 there is a method cl::sycl::program::get_info, which allows to query build logs, but I can't see any equivalent of this API in SYCL 2020 (except for maybe interoperability interfaces or backend-specific interfaces).
Am I missing something? Was this change intentional?
I'm concerned that the ability to print build logs could be useful, to understand what exactly went wrong or even in successful build logs could contain some warnings or additional information about the build, like optimization report, for example.
Even if the decision would be not to introduce this API, does it make sense to provide a guarantee for user, that build exception will contain build logs for user to understand what went wrong?
The text was updated successfully, but these errors were encountered:
I think most implementations would return the build log as part of the what string of the errc::build exception that is thrown for a failed compile or link operation. I'm not sure it makes sense to require this in the specification, though. Instead, this seems like a quality of implementation thing. An implementation could choose not to return any message in the what string, but this would be a poor quality implementation.
Even if we did require this in the spec, I'm not sure how we could test for it. We don't mandate any specific format or content of the what string, and there's no other place in the spec where we mandate the content of the what string.
In SYCL 1.2.1 there is a method
cl::sycl::program::get_info
, which allows to query build logs, but I can't see any equivalent of this API in SYCL 2020 (except for maybe interoperability interfaces or backend-specific interfaces).Am I missing something? Was this change intentional?
I'm concerned that the ability to print build logs could be useful, to understand what exactly went wrong or even in successful build logs could contain some warnings or additional information about the build, like optimization report, for example.
Even if the decision would be not to introduce this API, does it make sense to provide a guarantee for user, that
build
exception will contain build logs for user to understand what went wrong?The text was updated successfully, but these errors were encountered: