Skip to content

Conversation

@uditagarwal97
Copy link
Contributor

No description provided.

@uditagarwal97 uditagarwal97 self-assigned this Sep 2, 2025
@uditagarwal97 uditagarwal97 requested a review from a team as a code owner September 2, 2025 22:30
Comment on lines 30 to 31
DeviceGlobalMap(const DeviceGlobalMap &) = default;
DeviceGlobalMap &operator=(const DeviceGlobalMap &) = default;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rule of three

DeviceGlobalMap(const DeviceGlobalMap &) = default;
DeviceGlobalMap &operator=(const DeviceGlobalMap &) = default;

~DeviceGlobalMap() noexcept(false) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverity is complaining about C++ destructor implicitly marked as noexcept while the destructor body can throw an exception, in DeviceGlobalIt.second->cleanup();.
I've marked the destructor as noexcept(false) to indicate that destructor can throw

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is a good solution. I tried it once and it just lead to more Coverity hits.

If this class is destroyed in any OTHER classes destructor, then the problem recurs. Do you mark that destructor as noexcept(false) too?

I guess many of our impl classes now have try/catch blocks and they stream out errors. But should that occur it'll likely be difficult to trace the problem back to here.

Anyway, I haven't thought about this deeply, and perhaps in this situation you have. Just wanted to check.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is a good solution. I tried it once and it just lead to more Coverity hits.

If this class is destroyed in any OTHER classes destructor, then the problem recurs. Do you mark that destructor as noexcept(false) too?

I see. If this solution leads to more Coverity hits, I'd be in favor of using try/catch instead, similar to what you did in #14273

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 7627f88

m_default_event_type = (uint16_t)xpti::trace_event_type_t::algorithm;
m_default_activity_type = xpti::trace_activity_type_t::active;
m_default_name = "Message"; // Likely never used
m_instID = 0;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coverity was complaining about this field be left uninitialized in the constructor.

@uditagarwal97 uditagarwal97 merged commit 9c7b769 into sycl Sep 3, 2025
43 of 44 checks passed
@uditagarwal97 uditagarwal97 deleted the private/udit/coverity_bugs branch September 3, 2025 23:26
AlexeySachkov pushed a commit to AlexeySachkov/llvm that referenced this pull request Sep 10, 2025
AlexeySachkov added a commit that referenced this pull request Sep 11, 2025
This is a cherry-pick of #19952

Patch-by: Udit Kumar Agarwal <[email protected]>
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.

3 participants