https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105171
--- Comment #6 from PaX Team <pageexec at gmail dot com> --- (In reply to Andrew Pinski from comment #5) > > So that I can decide whether I am allowed to do things totally randomly > > or if I must follow some sort of seeded determinism. > > That is almost always the wrong approach really. > Just assume the seed it always set and then use the seed as given. Don't > ever do something non-determinstic if you can avoid it. GCC has changed > away from that years ago. 'almost always' is the keyword here as there are situations where 1. we want to introduce compile time randomness into the compilation, 2. use gcc's PRNG or something else. case in point, our structure layout randomization gcc plugin that is now even in upstream linux. the problem is the decision in requirement #2 as so called 'reproducible builds' won't work too well without knowing whether the user wanted to control gcc's PRNG via -frandom-seed. this decision should be made based upon 'local_tick' but due to its undersized nature (should be u64) it can lead to false decisions. that's the bug we're talking about, other uses may or may not suffer but at this point are irreleant really. > The coverage.cc is a non-issue as libgcov will do the right thing as > mentioned. you didn't mention the 'why'. the conditional expression can falsely execute the unlink even when the file's uniquely stamped but the seed just happened to be 0 or -1 due to the bug. if those seed values don't matter then the comment and the conditional are wrong.
