A series of unary operators and casts may obscure the variable we're
trying to analyze. Ignore them for the uninitialized value analysis.
Other checks determine if the unary operators result in a valid l-value.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I tested the problematic Linux kernel configuration that uncovered this issue with this patch and the issue was resolved. I tested an x86_64 allmodconfig build and did not see any warnings.
clang/lib/Analysis/UninitializedValues.cpp | ||
---|---|---|
594–595 | Should "it's don't count" be "don't count"? |
Pretend that I've spoken English for most of my lyfe.
clang/lib/Analysis/UninitializedValues.cpp | ||
---|---|---|
594–595 | You does not like mine English? :-P |
clang/lib/Analysis/UninitializedValues.cpp | ||
---|---|---|
819–820 | Q: are there any unary operators that are not casts? For example isn't something like -x a unary negation operator? I worry that this could be an infinite loop as written. If this fear is unfounded, then I think the code could be rewritten as: while (const auto *UO = dyn_cast<UnaryOperator>(Ex)) Ex = stripCasts(C, UO->getSubExpr()); |
clang/lib/Analysis/UninitializedValues.cpp | ||
---|---|---|
819–820 | It's not just casts that I want to remove. In particular, the & and * operators need to be removed to get to the variable. It *should* eventually get to a variable or non-unary expression once it goes through all of the unary operators and casts. Note there are other sema checks that determine if the expression is a proper l-value, so I can throw away the unary-ops. |
clang/lib/Analysis/UninitializedValues.cpp | ||
---|---|---|
819–820 | Ok, my original concern seems fine. I still think you should rewrite the loop as suggested. At the least, a dyn_cast shouldn't be necessary once we've already checked with isa; cast could simply be used. Or even better just one dyn_cast as suggested. |
Should "it's don't count" be "don't count"?