kadircet wrote: ok so I did a little more investigation here, and tl;dr is: - LLVM's target registry mechanism relies on static initialization of variables by the main driver program (usually clang driver takes care of this for real world runs). - There are some tests (especially the ones that make use of `CodeGenAction`) that'll succeed when no targets are registered, or when all targets are registered properly, but would fail when targets are registered partially (i.e. we know the target infos, but we don't know target mcs). - Because these registries are shared across the process, behavior being tested starts to rely on test execution order (as some tests end up registering these targets). - There's a very good chance execution order gets shuffled with every commit that introduces a clang unit test, since db2315afa8db1153e3b85d452cd14d5a1b957350. We basically have a single process for all the unit tests now, whereas these interactions were limited to ~per unit-test directory before (still problematic before that change, but issues were localized and less likely to change at every commit). - These types of failures were also addressed in the [commit](https://github.com/llvm/llvm-project/commit/db2315afa8db1153e3b85d452cd14d5a1b957350#diff-20471d97c4d6508fa8db379e50d61635f777fbd08ed4da22a3f07d8c54ab9882) mentioned above.
going to mention this in the original commit to see what authors think. https://github.com/llvm/llvm-project/pull/143695 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
