Register allocation
This may appear to be a weird answer, but consider these other questions: How many registers are necessary to arrange and call these functions? How many registers to keep alive or spill to memory, to care for intermediate results? What registers are clobbered in general or in this particular case? How much do these questions change on other machines?
These questions need not be answered in general, because C was created to abstract away these machine details and ABI conventions. Yet, C is about generating assembly and binary objects, where these questions are paramount.
Having all this unspecified allows for all sorts of micro optimizations at register allocation level.
And, I suspect, also allows some other tricks at source level, because many compound expressions can be freely (and fully) reordered then is possible, in principle, to examining all combinatorial arrangements of unsequenced subexpressions, to find some combination that uses less or spills less registers in the alternatives.
Divergent incompatible historicalhistorical implementations
I would also echo the excellent and eloquent points of Eric Lippert and Steve on the comments of the question (and encourage them to elaborate in answers), to point out that the history of C plays a very salient role here.
These details are underspecified on the standardstandard of the language, not to enable unspecified future optimizations, but to accommodate various divergent incompatible incompatiblehistorical behaviours in various compilers. Where in one vendor, compiler, or particular machine, one particular optimization is culturally acceptable, desirable and even necessary, in another it was not.
But by the time of language standardization, these incompatibilities were not or could not be worked on, so most of these historical incompatibilities optimizations were left intentionally unspecified.
