https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to uecker from comment #26) > (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 ECF_LOOPING_CONST doesn't exist, you imply ECF_CONST|ECF_LOOPING_CONST_OR_PURE, that would be sufficient for the testcase at hand I think. ECF_LOOPING_CONST_OR_PURE means the function might not return (it might contain a while(1) {} loop). That the function might not return is what we are really after as a property to properly inhibit the optimizations we do not want.
