https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121936
--- Comment #29 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Matthias Kretz (Vir) from comment #28) > (In reply to Iain Sandoe from comment #0) > > This is not valid if the evaluation depends on any content of the callee > > that is "unspecified" per the language standard(s). […] > > > > This is wrong code because a different implementation can choose to evaluate > > the arguments in a different order, […] > > I don't believe this optimization is not conforming. > > Looking at https://eel.is/c++draft/defns.unspecified, "unspecified behavior" > means "behavior […] that depends on the implementation". completely agreed - it is conforming for different compilers to make different choices here .. > Or in this specific case we get "GCC depends on the behavior of GCC". I > don't see how the standard takes issue with that. Now, maybe we want to give > the additional guarantee that "GCC depends on the behavior that is equal > among all GCC-compatible compilers" (or something similar). But, do we > really? Well, currently we don't for this particular thing - we could have chosen to make it part of the ABI, in which case compilers claiming support for that ABI would do the same thing and all would be OK. The point of the example, was (and is) that we have multiple [non-contracts-related] situations in which conforming compilers can make changes that invalidate acting on the visible body of an inline function *unless* you are really going to inline it.
