tree 1ca4925cc57d14fdb810cb8e298ff9c6e7fd16f0
parent 830a2911ee164e32a5459e2991233afb7168c812
author Balazs Benics <benicsbalazs@gmail.com> 1739372869 +0100
committer GitHub <noreply@github.com> 1739372869 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJnrLlFCRC1aQ7uu5UhlAAAZgEQAHXBX2LiPXih1BxJB4MhagwB
 0MWNQ9ZOBGG/2GZm8HdrF3Wa3+mi15WvetxB4ge0Qsj+Zf/RxF6dnpP2USEOrY47
 1w4+fmwGcp0+9Z6C3HsSbCrTuaR4Oo0Cqvj2fGPmGWUycVaAn2/SMt0f1ycOlqj9
 6ToV7V+5nxVIJI9Svy3535aYW/9asWjJOFehzQeKuMRqD65184cPMjg5ohXLye4O
 RGeaKGmxVMoeJmElmyC4GIXesUhY+wPN7OOATYPhkFiGpLQj/hektXU9/XHGfkC9
 L+0mnUuD+/9h1KSSAV9mJ5cxZsNDoLl8Y7jnR92TL1F+s8MHRE9JbApjTOOKXW8j
 dSNj0uc8oYsKOl8aRFXxuF0aNC1RCDu+MS9bODnLMtzeNaNafYz7Oz+lE6M4zRfq
 a26pnh+2AwnBDDTcJa8wtWvAkPYsmuRVw8tEhpLC11H0bNi/2zbQGJyPZueK0tcZ
 n+fU9YzqcLlcZdXFS0ouz7gZcEF9cC6Erhas5jcjJpgI+dIxpyihHFckyBpIxsZE
 P7qcwN+q121LcOWXWhmarQdclBRpdGVl6l9uavIBUH+RiddCW5Hs36qOIj4nrv9q
 gohOvIvUdPirXzOri85ESkPNVatBsgm5Ko+EyiwQwypdEssZEckKu4QaBarNfPMS
 HFj7UmlCAb5qr307ftS3
 =83Ru
 -----END PGP SIGNATURE-----
 

[clang][analysis] Fix flaky clang/test/Analysis/live-stmts.cpp test (#126913)

Multiple people reported flaky bot failures tied to
`clang/test/Analysis/live-stmts.cpp` I tried reproducing the flaky
behavior on my Linux x86_64 system, but the tests appears to be stable
in my context.

Only by looking at the failures reported, I could formulate a potential
diagnosis.
The output always looked almost the same, except that the Exprs dumped
per Basic block were shuffled compared to my expectation. This suggests
to me some ordering issue.

If you look at the backing storage of
`blocksEndToLiveness[B].liveExprs`,
it uses `llvm::ImmutableSet<const Expr *>`.
That container likely uses the pointer values as keys, thus the runtime
values of the addresses influence the iteration order.

To fix this, before dumping, I sort the expressions by their
"beginLocs". It should be efficient enough for a debug checker, where
there is no performance constraint.

This should hopefully fix the flaky behavior on systems where ASLR works
differently than (my) Linux system.

Hopefully fixes #126619
Hopefully fixes #126804