mgrang added a comment. In D59279#1438500 <https://reviews.llvm.org/D59279#1438500>, @rnkovacs wrote:
> In D59279#1427017 <https://reviews.llvm.org/D59279#1427017>, @mgrang wrote: > > > Following are the assumptions/limitations of this patch: > > > > 1. The assumption is that iteration of ordered containers of pointers is > > not non-deterministic. > > > > > Could you please explain which type of non-determinism we are addressing > here? If our issue is that iteration order is not consistent across runs, > then an unordered set of //integers// seems just as non-deterministic as an > unordered set of //pointers//. On the other hand, if our issue is that > pointer values vary between runs, then an //ordered// set of pointers seems > just as non-deterministic as an //unordered// set of pointers. Are > //unordered// sets of //pointers// distinguished because they lie in the > intersection of these categories and thus avoid the most false positive > cases? If so, for someone debugging non-deterministic behavior in their code, > would it be useful to add a strict option that shows other cases too? If not, > maybe we could document our reasons somewhere. Yes, the reason we limit the checks only to //unordered// containers is to reduce the false positive rate. Although, as you rightly pointed out that //ordered// sets of pointers are as non-deterministic as //unordered// ones. Once our checks have the capability to detect what happens inside the loop maybe we can add //ordered// sets too. I will add this to the TODO. Thanks. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59279/new/ https://reviews.llvm.org/D59279 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
