all code is deterministic for a given input. If you don't understand the behavior, it's because you don't understand the complete set of inputs into the system.

Assuming you're not tripping over some hardware defect, it sounds like you're using a gcc hack that llvm doesn't support

for a display update, sounds like memory ordering

Re determinism: that's what we'd like to believe, but it's true only if we redefine input to include overall build and execution context, and the latter is generally unreproducible. Over the last few years I've seen plenty of subtle bugs, some caused by UB, some caused by interactions with the overall execution environment, that resulted in mostly correct but sometimes wild and haphazard results, all for the same "input".

Once these bugs were fixed, things became deterministic, but to say that all software is deterministic is to assert some level of programming, build, and operational consistency that is often achievable with great effort.

Re gcc hacks: nope. No gcc'isms anywhere in the code, all warnings enabled, no warnings produced, just one case where a field is not updated in one very specific set of circumstances. Thanks for the suggestion, but that was one of the first things we thought of. There is a slight chance that it is actually a clang/llvm call stack depth bug, but the effort to reproduce that outweighs the impact of the bug, what with one thing and another not relevant here.

UB -> occasional non-determinism.