[Bug tree-optimization/108552] Linux i386 kernel 5.14 memory corruption for pre_compound_page() when gcov is enabled

["torvalds@linux-foundation.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552

--- Comment #30 from Linus Torvalds <torvalds@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).