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

coverity issue in generated CUDA kernels #221

Open
raffenet opened this issue Mar 29, 2022 · 0 comments
Open

coverity issue in generated CUDA kernels #221

raffenet opened this issue Mar 29, 2022 · 0 comments

Comments

@raffenet
Copy link
Contributor

raffenet commented Mar 29, 2022

Coverity's static analysis does not like this pattern in the CUDA generated code. From yaksuri_cudai_kernel_pack_SUM_hvector_hindexed_int16_t.

[...]
    uintptr_t x3;
    for (intptr_t i = 0; i < md->u.hvector.child->u.hindexed.count; i++) {
            uintptr_t in_elems = md->u.hvector.child->u.hindexed.array_of_blocklengths[i] *
                                 md->u.hvector.child->u.hindexed.child->num_elements;
            if (res < in_elems) {
                    x3 = i;
                    res %= in_elems;
                    inner_elements = md->u.hvector.child->u.hindexed.child->num_elements;
                    break;
            } else {
                    res -= in_elems;
            }
    }
[...]

If the loop exist without the if (res < in_elems) branch ever being taken, then x3 will be uninitialized when it is used later on in the function.

  1. What is uintptr_t res representing in this context? It could benefit from a better name.
  2. How can we modify the loop to guarantee static analysis sees x3 as having a valid value?
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

No branches or pull requests

1 participant