https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121936
--- Comment #19 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #13)
> Note GCC has can does the order depending on an option/target even:
> for (i = (PUSH_ARGS_REVERSED ? nargs - 1 : 0);
> PUSH_ARGS_REVERSED ? i >= 0 : i < nargs;
> PUSH_ARGS_REVERSED ? i-- : i++)
> {
> Right now GCC does it for the following targets:
> config/bpf/bpf.h:#define PUSH_ARGS_REVERSED 1
> config/i386/i386.h:#define PUSH_ARGS_REVERSED 1
> config/nvptx/nvptx.h:#define PUSH_ARGS_REVERSED 1
IIRC this was done because it is more efficient to compute the values in the
order that you want to push them onto the stack, especially on machines with
very few registers.
It would not surprise me if the fact that evaluation order is unspecified in
the standards was exactly to permit implementations to do this kind of thing.
> I wonder if this should be removed.
It would not make any difference to the practical issue (and we might be
getting side-tracked with details):
ODR is perhaps not as strong a promise as we'd like - because "the same
sequence of tokens" can include
- tokens that implement standard-mandated behaviour (which we could rely on
for optimisation, since it must be the same in all versions)
- tokens which implement unspecified behaviour (which we must not use for
optimisation)
When we view a function as a "black box" with an interface mandated by the ABI
- then we consider that the ODR makes the behaviour always the same; in fact,
that's not 100% true - the computed result might always be the same, but the
speed of computation could be completely different; as a community we have
decide to live with this.
However unless/until it would be possible to differentiate between the
specified and unspecified behaviour of the function (when examining it
internally, not through the isolation of the ABI) .. we cannot safely use its
details to optimise.
Richard gave some other examples of things that could change - I only used the
evaluation order because it was reasonably easy to make a reproducer - we
should not get hung up on that specific case (since the issue is more general).
