https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #30 from Linus Torvalds <torva...@linux-foundation.org> --- (In reply to Richard Biener from comment #26) > And yes, to IV optimization the gcov counter for the loop body is just > another IV candidate that can be used, and in this case it allows to elide > the otherwise > unused original IV. Ouch. So we really don't mind the data race - the gcov data is obviously not primary - but I don't think anybody expected the data race on the gcov data that isn't "semantically visible" to then affect actual semantics. And yeah, atomic updates would be too expensive even on 64-bit architectures, so we pretty much *depend* on the data race being there. And on 32-bit architectures (at least i386), atomic 64-bit ones go from "expensive" to "ludicrously complicated" (ie to get a 64-bit atomic update you'd need to start doing cmpxchg8b loops or something). So I think the data race is not just what we expected, it's fundamental. Just the "mix it with semantics" ends up being less than optimal. Having the gcov data be treated as 'volatile' would be one option, but probably cause horrendous code generation issues as Jakub says. Although I have several times hit that "I want to just update a volatile in memory, I wish gcc would just be happy to combine a 'read-modify-update' to a single instruction". So in a perfect world, that would be fixed too. I guess from a kernel perspective, we might need to really document that GCOV has these issues, and you can't use it for any real work. We have just been lucky this hasn't hit us (admittedly because it's fairly odd that an expected end gcov value would end up being used in that secondary way as a loop variable).
