steakhal wrote: > > I'm not sure I see why. The logs I linked in the revert only showed a > > single test failure. The new test we added in this PR. This suggests close > > correlations. Maybe the content of the "constraints" map in the State is > > dumped in a non-deterministic order? And we just happened to step on it now. > > Yes it's the testcase touched by this PR that failed (not other random > testcase inside the repo). > > I mean that clang behaves randomly. > > The randomness might not be introduced by this PR but by some earlier commit > point. > > I'm working on it.
Be aware of that llvm DenseMap and sets are basically open-address hashtables, and the hash function is seeded by the address of some known function (IDK which). This means that these tables depend on where clang is loaded in memory. Consequently, address-space layout randomization could affect the reproducibility of some issues and lead to flaky cases. The constraints are backed by llvm::Immutable map and set. which is some AVL-tree if I recall. I'm not sure how the "ordering" is implemented there but if they are in terms of comparing pointer addresses then we might have a problem. When dumping the constraints, I think we just iterate the AVL-tree from begin to end, which will prefer "less-then" elements, but if those depend on where the process is loaded then the whole iteration order is RT dependent. Could you please check if we sort before dumping the constraints? https://github.com/llvm/llvm-project/pull/115579 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
