Skip to content
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

Merged
merged 12 commits into from
Sep 6, 2024

Conversation

ianayl
Copy link
Contributor

@ianayl ianayl commented Aug 30, 2024

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 initialized MSizeInBytes of the SYCLMemObjT class to 0: This should not cause any problems (at least not more), as currently all subclasses of SYCLMemObjT that actually use the MSizeInBytes have it defined (buffer_impl, image_impl) when their respective constructors are called. However, this does mean programmers must remember to initialize MSizeInBytes when using image_impl.

To avoid this, I could rewrite some of the constructors in e.g. image_impl and SYCLMemObjT, 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!

@ianayl ianayl marked this pull request as ready for review September 4, 2024 04:58
@ianayl ianayl requested a review from a team as a code owner September 4, 2024 04:58
@uditagarwal97
Copy link
Contributor

I think initializing MSizeInBytes with 0 is fine, better than keeping it uninitialized.

@ianayl
Copy link
Contributor Author

ianayl commented Sep 5, 2024

@intel/llvm-gatekeepers This PR should be ready, thanks!

Copy link
Contributor

@uditagarwal97 uditagarwal97 left a 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.

Copy link
Contributor

@uditagarwal97 uditagarwal97 left a 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

@ianayl
Copy link
Contributor Author

ianayl commented Sep 6, 2024

@intel/llvm-gatekeepers Sorry for previous ping, but this PR should now actually be ready, thanks in advance!

@sarnex sarnex merged commit 0546dc1 into intel:sycl Sep 6, 2024
13 checks passed
sommerlukas pushed a commit that referenced this pull request Sep 10, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants