This is the mail archive of the
mailing list for the GCC project.
Re: C++ order of evaluation of operands, arguments
- From: David Brown <david dot brown at hesbynett dot no>
- To: Michael Matz <matz at suse dot de>, Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, GCC <gcc at gcc dot gnu dot org>
- Date: Thu, 26 Nov 2015 10:55:03 +0100
- Subject: Re: C++ order of evaluation of operands, arguments
- Authentication-results: sourceware.org; auth=none
- References: <56539AD0 dot 80905 at redhat dot com> <CAFiYyc2zzFFPEd27aQwjHp4q+UvDquu52CF1+sqPSs3hVjD=_A at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1511251540500 dot 11029 at wotan dot suse dot de>
On 25/11/15 15:47, Michael Matz wrote:
> On Tue, 24 Nov 2015, Richard Biener wrote:
>> On Tue, Nov 24, 2015 at 12:01 AM, Jason Merrill <email@example.com> wrote:
>>> There's a proposal working through the C++ committee to define the order of
>>> evaluation of subexpressions that previously had unspecified ordering:
>>> I agree with much of this, but was concerned about the proposal to define
>>> order of evaluation of function arguments as left-to-right, since GCC does
>>> right-to-left on PUSH_ARGS_REVERSED targets, including x86_64.
> Actually the most natural order for an (normal, stack-passing)
> implementation that supports varargs is right-to-left, so the proposal has
> it exactly backwards. (Reason being that named arguments then have
> constant offsets from stack pointer).
> right-to-left is also the better order for all ABIs that pass (at least
> some) arguments on stack but give left arguments smaller offsets from
> top-of-stack (as most ABIs do).
That is all true - but if you have to pick an order that makes sense to
users, especially of functions that are not varargs (i.e., most
functions), then left-to-right is the only logical, natural order - at
least for those of use who use left-to-right languages.
How often would left-to-right evaluation actually cause efficiency
problems? It would only be for functions that take a lot of parameters
or a variable number of parameters, and then only when calling them with
arguments that are calculated in a way that might have side-effects
(otherwise the compiler is free to re-order them anyway). Is that
really going to be a big issue? One should not limit the language just
because of a tiny efficiency issue with rarely-used cases.
(The other orderings discussed in the proposal seem fair enough - it is
only function parameter ordering that is an issue, I think.)