https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800
--- Comment #29 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 14 Sep 2026, uecker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104800 > > --- Comment #28 from uecker at gcc dot gnu.org --- > (In reply to Richard Biener from comment #27) > > (In reply to uecker from comment #26) > > > (In reply to Richard Biener from comment #25) > > > > > > > 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, > > Ah right. > > > 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. > > Sufficient for a modified test case with "volatile" on the variable. The > global write without volatile is ok to remove in C (but I need to check for > C++) and if I understand you correctly, changing to would > ECF_CONST|ECF_LOOPING_CONST_OR_PURE would allow this. It would not prevent DSE, yes. Like x = 1; <barrier> x = 2; would still elide the first x iff <barrier> is const. Whether this would happen for the function w/o return I'm not sure.
