https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #42 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #40)
> (In reply to Jan Hubicka from comment #39)
> > I was wonering if we should not provide flag to turn all counts
> > volatile. That way we will still have race conditions on their updates
> > (and it would be chepaer than atomic) but we won't run into such wrong
> > code issues nor large profile mismatches.
>
> Yes, see above. Or a mode in which we would just avoid hoisting and sinking
> the gcov vars but keep them non-volatile. Or both.
> But I guess it would be nice to get Vlad's patch into trunk and release
> branches for now (perhaps with an extra check for startswith "__gcov" on
> DECL_NAME, so that we don't do it for the Fortran tokens).
>
> As for the patch, just small nits, I think get_base_address returns always
> non-NULL, so it could be
> if (tree expr = MEM_EXPR (res))
> {
> expr = get_base_address (expr);
> if (VAR_P (expr)
> && DECL_NONALIASED (expr)
> && DECL_NAME (expr))
> {
> const char *name = IDENTIFIER_POINTER (DECL_NAME (expr));
> /* Don't reread coverage counters from memory, if single
> update model is used in threaded code, other threads
> could change the counters concurrently. See PR108552. */
> if (startswith (name, "__gcov"))
> return x;
> }
> }
Note that this isn't exactly reliable but a heuristic workaround since
MEM_EXPRs are optional and dropping them is valid (and done in some places).
I think if we want to avoid doing optimizations on gcov counters we should
make them volatile. I suppose kernel folks would have a way to assess
any "catastrophic consequences" on optimization? (I have a hard time
imagining them, sure that RMW will not allow add with memory operand,
but that's it?)
