NoQ added a comment. Hmm, well, i guess it's not going to be a one-liner. You might have to iterate through all live variables in the scope, see if they are references, and add the trait. I think currently there's no way around scanning the current function body (i.e. `LCtx->getDecl()`, where `LCtx` is `Pred->getLocationContext()`) an AST visitor or an AST matcher. Once that's done, you can take `Pred->getState()->getLValue(VD, LCtx)` for every `const VarDecl *` `VD` you find and set the invalidation trait on that. It might be necessary to restrict your search to active variables (in the sense of `LCtx->getAnalysis<RelaxedLiveVariables>()->isLive(S, VD)`), where `S` is... dunno, some statement that makes sense here.
Probably global/static references should also not be invalidated. It'd take even more effort to find those. I still think it's worth it because widening is indeed at fault, not the common destructor handling code. The assertion you step upon (that the `cast<>` always succeeds) is a valuable assertion that helped us find that bug, we shouldn't suppress it. Loop widening in its current form is an experiment that was never announced to work, and, well, yeah, it has this sort of bugs. There is work started by @szepet in https://reviews.llvm.org/D36690 to turn widening into a whitelist-like thing. Repository: rC Clang https://reviews.llvm.org/D47044 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
