https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #39 from Jan Hubicka <hubicka at ucw dot cz> --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552 > > --- Comment #35 from Vladimir Makarov <vmakarov at gcc dot gnu.org> --- > (In reply to Jakub Jelinek from comment #34) > > Seems right now DECL_NONALIASED is only used on these coverage vars and on > > Fortran caf tokens, so perhaps a quick workaround would be on the LRA side > > never reread stuff from MEMs with VAR_P && DECL_NONALIASED MEM_EXPRs. CCing > > Vlad on that. > > The following patch can do this: Note that with threads we often get large profile mismatches when the load/stores are hoisted out of the loop. I.e. for (....) gcov_count++; to i = gcov_count for (.....) i++ gocv_count = i If the second loop is run in parallel a lot of increments may be lost. 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.
