https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108552
--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess we should try and see.
For volatile,
--- gcc/coverage.cc 2023-01-02 09:32:37.078072992 +0100
+++ gcc/coverage.cc 2023-01-30 09:24:45.219951352 +0100
@@ -774,6 +774,7 @@ build_var (tree fn_decl, tree type, int
TREE_STATIC (var) = 1;
TREE_ADDRESSABLE (var) = 1;
DECL_NONALIASED (var) = 1;
+ TREE_THIS_VOLATILE (var) = 1;
SET_DECL_ALIGN (var, TYPE_ALIGN (type));
return var;
would do it I think (but it should be conditional on new -fupdate-profile
modes, single-volatile and prefer-atomic-volatile or something similar).
Or perhaps insert asm volatile ("" : "+g" (tmp)); in between the load and store
and see how that compares to the volatile vars? Or adding another flag on the
gcov vars next to DECL_NONALIASED and just avoid specific optimizations on it
that somebody runs into (not as reliable but could be faster) - for now
hoisting in LIM and sinking.
