http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57723
--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> --- (In reply to petschy from comment #7) > Is it a plausible assumption that if a function is not marked as 'noreturn' > and the loop doesn't change the program's state then the loop could be > optimized away? It's not unplausible, but still wrong, see below. GCC optimizes empty loops only away if the functions containing them are marked pure or const (the argument being that an infinite loop is in itself a side-effect observable from outside). This could be extended to also do that for functions without the noreturn attribute. But it would be a relatively large change in semantics. That is because noreturn attributes are optional; functions that don't return aren't required to be so marked, so in practice a missing noreturn attribute doesn't mean anything. So, when GCC starts to remove infinite loops in functions missing it (in practice most functions) this might change behaviour (which you already can have with the unsafe-loop-optimization flag). The problem lies with multi-threaded programs. A function containing an infinite loop could be stopped from a different thread. While I'll happily admit that this is a quite unlikely behaviour, you can construct a valid program that will break with infinite-loop removal. So it seems that if any other attribute should trigger this in addition to const/pure (which have other effects of course), it would have to be a new one, with positive meaning, ala "this-function-does-return". I'm not aware of anyone sufficiently motivated to work on this. Perhaps you are, if so, look for finite_loop_p() in tree-ssa-loop-niter.c for the place to lookup the new attribute, and builtin-attrs.def for the place to define a new attribute. > Cases: > - the loop terminates, but the state is not changed, NOP > - the loop does not terminate (in this case a cycle of the Node's), but the > function should return (no noreturn attr), so this is probably a bug in the > prg > > I can't think of any cases right now for the second point where that would > be the desired behaviour of the program, instead of a bug. Please comment on > this. See the multi-threading example.
