🚀 go-pugleaf

While researching the ``gcc.texi'' file in preparation for my last bug
report (to determine whether the problem was a result of deliberate
non-compliance or a genuine bug), I came across the following:

	@example
	void func (int, int);

	int i = 2;
	func (i++, i++);
	@end example

	There is no guarantee (in either the C or the C++ standard language
	definitions) that the increments will be evaluated in any particular
	order.  Either increment might happen first.  @code{func} might get the
	arguments @samp{2, 3}, or it might get @samp{3, 2}, or even @samp{2, 2}.

This is incorrect. Yes, in the C language standard, it is written that
the evaluation order of function arguments is unspecified. However, it is
also stated that there is a sequence point before the actual function call
(but not between the argument evaluations), and that the effect of modifying
an object more than once between sequence points is undefined. Hence func(i++,
i++) is UNDEFINED behavior, not UNSPECIFIED behavior. It is therefore false to
say that either increment might happen first: the language description makes
no particular requirements on the translation of undefined behavior.
The function could get 42, 42 yet the compiler could still be
considered conforming.