-
Notifications
You must be signed in to change notification settings - Fork 738
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SYCL] Fix uninitialized fields Coverity hits #15237
Conversation
This reverts commit 0e043b8.
I think initializing |
@intel/llvm-gatekeepers This PR should be ready, thanks! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 to the fix Kseniya suggested.
just initialize to 0 (it is integer var, "typedef uint32_t ur_exp_command_buffer_sync_point_t;"
Initialize MSyncPoint with 0 instead of std::optional.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making the changes, Ian :)
LGTM
@intel/llvm-gatekeepers Sorry for previous ping, but this PR should now actually be ready, thanks in advance! |
In the same vein as #15237, this PR fixes additional uninitialized values recently discovered by Coverity. Similar to the resolution discussed in #15237, I have default-initialized integer values that are defined later on to 0 instead of another more complex solution. Additionally, since I had set `MExternalSempahore` in `handler_impl` to `nullptr`, I added null checks where `MExternalSemaphore` is ultimately returned to ensure `nullptr` doesn't actually get passed into the UR. This is not necessarily necessary, but without this check Coverity would probably generate another hit because of it.
This PR fixes Coverity hits regarding uninitialized class fields in the runtime.
I'd like to bring attention to
sycl_mem_obj_t.hpp
however: There, I have initializedMSizeInBytes
of theSYCLMemObjT
class to 0: This should not cause any problems (at least not more), as currently all subclasses ofSYCLMemObjT
that actually use theMSizeInBytes
have it defined (buffer_impl
,image_impl
) when their respective constructors are called. However, this does mean programmers must remember to initializeMSizeInBytes
when usingimage_impl
.To avoid this, I could rewrite some of the constructors in e.g.
image_impl
andSYCLMemObjT
, but I'd like to not overcomplicate the problem here. So I was hoping for some other opinions: Is initializing as 0 sufficient, or should I go ahead and make the changes to the constructors anyway to be safe? Thanks in advance!