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

--- Comment #26 from uecker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #25)
> (In reply to uecker from comment #24)
> > For C++ a builtin was added that acts as a barrier for std::observable. This
> > could potentially be emitted by the C frontend after each volatile access. 
> 
> That would work, on the GIMPLE side at least.
> 
> > https://gcc.gnu.org/cgit/gcc/commit/
> > ?id=9056b5faa87df59fb8eb2f92096a8e6e7d246757
> > 
> > I do not understand the test case though, as the addition is not volatile,
> > so it may have stronger semantics than what is needed here. 
> 
> It depends on what is considered "observable", here the global variable
> write is supposedly so.
> 
> > (IIRC, in C the function without return would also not have UB as long as
> > the return value is not used.).

I assume ECF_LOOPING_CONST_OR_PURE means it can be assumed to read global
memory, so the store can not be sunk across the call and then eliminated.  So
it seems ECF_LOOPING_CONST would sufficient (for C at least, not sure about
C++), but this does not exist. But I am just speculating based on the comments
in tree-core.h

Reply via email to