Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #83406 > unrolled thread

GCC hasn't even gotten around to sequencing argument evaluation yet???

Back to article view | Back to comp.lang.c++

Contents

  GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-01 20:34 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-02 10:19 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bo Persson <bo@bo-persson.se> - 2022-04-02 12:19 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-02 14:18 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Gollwitzer <auriocus@gmx.de> - 2022-04-02 12:30 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-02 14:12 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Bonita Montero <Bonita.Montero@gmail.com> - 2022-04-02 14:20 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-02 14:28 +0000
          Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-02 17:27 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-02 15:39 +0000
              Re: GCC hasn't even gotten around to sequencing argument evaluation Barry Schwarz <schwarzb@delq.com> - 2022-04-02 09:15 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:21 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 12:02 +0200
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 14:42 +0000
                      Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 08:49 -0700
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:18 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:37 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:54 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-06 11:24 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Juha Nieminen <nospam@thanks.invalid> - 2022-04-06 10:49 +0000
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-06 18:21 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 15:40 +0100
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-06 15:00 +0000
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 17:03 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-04-06 17:18 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-07 08:58 +0000
                                        Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-07 11:01 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-04-06 23:13 +0200
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-07 09:11 +0200
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 10:53 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 14:50 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Sams Lara <samlara622@gmail.com> - 2022-04-06 22:27 +0100
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-06 14:51 -0700
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Sams Lara <samlara622@gmail.com> - 2022-04-06 22:59 +0100
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-06 15:54 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation Öö Tiib <ootiib@hot.ee> - 2022-04-06 15:11 -0700
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-09 09:38 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 23:48 -0400
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 18:39 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-06 23:49 -0400
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-05 08:55 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 10:23 -0700
                          Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:36 -0400
                      Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-04 12:27 -0400
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:21 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:41 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:50 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 10:19 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:33 -0400
                          Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-05 14:28 -0400
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 18:29 +0200
              Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 11:27 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:23 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 12:15 +0200
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 14:43 +0000
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 18:34 +0200
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:23 +0000
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 08:38 -0700
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-05 15:49 +0000
                              Re: GCC hasn't even gotten around to sequencing argument evaluation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-05 11:31 -0700
                                Re: GCC hasn't even gotten around to sequencing argument evaluation scott@slp53.sl.home (Scott Lurndal) - 2022-04-05 22:45 +0000
              Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-02 23:34 -0400
                Re: GCC hasn't even gotten around to sequencing argument evaluation Manfred <noname@add.invalid> - 2022-04-03 17:43 +0200
                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-03 15:40 -0400
                Re: GCC hasn't even gotten around to sequencing argument evaluation Muttley@dastardlyhq.com - 2022-04-04 08:24 +0000
                  Re: GCC hasn't even gotten around to sequencing argument evaluation James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-04-04 12:01 -0400
              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-03 13:02 +0200
                Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 04:46 -0700
                  Re: GCC hasn't even gotten around to sequencing argument evaluation Öö Tiib <ootiib@hot.ee> - 2022-04-03 07:02 -0700
                    Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 11:30 -0700
                      Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-03 21:20 +0200
                        Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 12:49 -0700
                          Re: GCC hasn't even gotten around to sequencing argument evaluation Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-04 00:40 +0300
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-03 15:40 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 09:13 +0200
                          Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 09:02 +0200
                            Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-04 02:07 -0700
                              Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 13:28 +0200
                                Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-04 06:01 -0700
                                  Re: GCC hasn't even gotten around to sequencing argument evaluation David Brown <david.brown@hesbynett.no> - 2022-04-04 19:11 +0200
                                    Re: GCC hasn't even gotten around to sequencing argument evaluation scott@slp53.sl.home (Scott Lurndal) - 2022-04-04 17:59 +0000
                                      Re: GCC hasn't even gotten around to sequencing argument evaluation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2022-04-05 06:55 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation Manfred <noname@add.invalid> - 2022-04-03 18:39 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation Paavo Helde <eesnimi@osa.pri.ee> - 2022-04-03 09:09 +0300
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-02 19:53 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-03 13:45 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-03 17:27 +0200
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-02 21:17 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@invalid.add> - 2022-04-02 23:04 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-03 00:22 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 17:33 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-03 14:23 +0100
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-06 08:31 -0700
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-06 11:05 -0700
                Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-04-25 03:32 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 11:18 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-02 13:11 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manu Raju <MR@invalid.invalid> - 2022-04-02 18:26 +0100
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manu Raju <MR@invalid.invalid> - 2022-04-02 21:46 +0100
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-02 17:35 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Language Lawyer <language.lawyer@gmail.com> - 2022-04-04 02:28 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 05:52 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Language Lawyer <language.lawyer@gmail.com> - 2022-06-21 03:36 -0700
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Juha Nieminen <nospam@thanks.invalid> - 2022-04-04 10:48 +0000
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-04 05:49 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Juha Nieminen <nospam@thanks.invalid> - 2022-04-05 06:34 +0000
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-04-05 10:20 +0100
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-05 07:51 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Manfred <noname@add.invalid> - 2022-04-05 17:53 +0200
    Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 06:06 +0200
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-09 21:20 -0700
      Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-09 21:39 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-09 22:34 -0700
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 09:19 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? David Brown <david.brown@hesbynett.no> - 2022-04-10 12:21 +0200
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 12:47 +0200
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-11 12:18 -0700
              Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-04-11 12:33 -0700
        Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Christian Hanné <the.hanne@gmail.com> - 2022-04-10 09:20 +0200
          Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2022-04-11 12:32 -0700
            Re: GCC hasn't even gotten around to sequencing argument evaluation yet??? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-04-11 15:11 -0700

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#83502 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 06/04/2022 12:49, Juha Nieminen wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> As long as the results are the same for any possible values of the
>> variables for which there are no signed overflows in original
>> expression, any order of evaluation is allowed.
> 
> While not completely relevant to this discussion, this somehow reminded
> me of the gcc (and clang) option -ffast-math, which gives the compiler
> express permission to do (floating point) optimizations that are,
> strictly speaking, not allowed by the standard (because according to
> the standard optimizations must not affect observable behavior, other
> than runtime).
> 

I am no expert on the details of floating point conformance (for my uses 
of floating point, -ffast-math is ideal).  But I believe many aspects 
are implementation-dependent.  So while gcc won't follow IEEE standards 
precisely when -ffast-math is in effect, it may still be conforming to 
the C standards.  I could be wrong here - as I say, it is not something 
I have looked at carefully.

> It can sometimes be a bit surprising what kind of optimizations the
> compiler is *not* allowed to perform, unless explicitly allowed to
> bypass the strictest requirements of the language standard.
> 
> For example, the compiler is not allowed to optimize "x*0.0"
> into "0.0" because that changes observable behavior if x is inf
> or NaN. (-ffast-math allows it to do that optimization.)
> 

This are not observable behaviour in itself (unless the implementation 
guarantees traps or signals).  Results of expressions are only going to 
be "observable" if they are stored in volatile variables, printed out, 
or otherwise affect the observable behaviour of the code.  If the value 
is not used, it is not observable.  (Of course, most calculations /will/ 
affect some observable behaviour - otherwise there would be no point in 
doing them!  But it is not the calculation itself that is observable.)

> Likewise it cannot optimize "(x+y)-x" into "y" because the result
> of the expression may not be exactly "y" (because of the limited
> size of the mantissa, or because "x+y" may result in inf or -inf.)
> The same is true for many other expressions that could mathematically
> be reduced but the compiler isn't allowed to do because with floating
> point the result may not be the same. (Again, -ffast-math gives it
> permission to do that type of optimization.)

Yes, indeed.

[toc] | [prev] | [next] | [standalone]

#83497 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Wed, 6 Apr 2022 11:24:39 +0200
David Brown <david.brown@hesbynett.no> wrote:
> You seem to have missed the point entirely.  Andrey is completely 
> correct here.  But perhaps the examples chosen have mislead you - while 
> a compiler is free to evaluate things any way it wants (as long as 
> observable behaviour is maintained), compilers don't go out of their way 
> to do things inefficiently.
> 
> Let's try some slightly more realistic examples, and see if you get the 
> point.
> 
> Say you write "x = a + (b - c);".  Maybe you've chosen parenthesis based 
> on what you know about the values of a, b, and c, and you know this way 
> no sub-expression overflows.
> 
> Do you think the compiler must do "b - c" first, then add "a" ?  If so, 
> you would be wrong.  It can evaluate in any order it likes as long as 
> the results have the same behaviour as the language semantics demand. 
> So it can happily do "a + b" and then subtract "c", or "a - c" and then 
> add "b", or negate "c" and then use a three-way add instruction if the 
> cpu has such a thing.
> 
> Given "a * (b + c)", the compiler might choose to evaluate "a * b", "a * 
> c", then add them together, if it has knowledge of the values that make 
> that more efficient (perhaps such re-ordering would let it use smaller 
> width multiplication instructions).  It could also re-order "(a * b) + 
> (a * c)" into "a * (b + c)" if that made more sense.
> 
> As long as the results are the same for any possible values of the 
> variables for which there are no signed overflows in original 
> expression, any order of evaluation is allowed.

Rereading the posts I suspect there is a more basic misunderstanding
than with respect to some rather improbable applications of the
observable effects rule to calculations without side effects.

Our Muttley appears to think that operator precedence determines the
order of evaluation of operands, which is wrong.  For example in the
expression "a + (b * c)", sub-expressions a, b and c can be evaluated
in any order the compiler chooses to determine. It can evaluate
operands left to right, right to left, or in any other order it
chooses.  In fact on my computer with -O2 optimisation both gcc and
clang evaluate left to right: they evaluate a and store the result,
evaluate b and store the result, evaluate c and store the result, then
carry out the multiplication and then carry out the addition.

In the example above the parentheses are unnecessary because of
operator precedence.  If I carry out a different arithmetic
calculation, namely "(a + b) * c", it evaluates operands a, b and c in
exactly the same order.  The difference is that as required by the
parantheses it sums the result of evaluating a and the result of
evaluating b before calculating their product with the result of
evaluating c.

[toc] | [prev] | [next] | [standalone]

#83498 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Wed, 6 Apr 2022 15:40:10 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Wed, 6 Apr 2022 11:24:39 +0200
>David Brown <david.brown@hesbynett.no> wrote:
>> As long as the results are the same for any possible values of the 
>> variables for which there are no signed overflows in original 
>> expression, any order of evaluation is allowed.
>
>Rereading the posts I suspect there is a more basic misunderstanding
>than with respect to some rather improbable applications of the
>observable effects rule to calculations without side effects.
>
>Our Muttley appears to think that operator precedence determines the
>order of evaluation of operands, which is wrong.  For example in the

Where did I say that?

>expression "a + (b * c)", sub-expressions a, b and c can be evaluated
>in any order the compiler chooses to determine. It can evaluate

I never said otherwise, but its not going to evaluate a+b is it when there's 
no point?

[toc] | [prev] | [next] | [standalone]

#83500 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Wed, 6 Apr 2022 15:00:29 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
> On Wed, 6 Apr 2022 15:40:10 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Wed, 6 Apr 2022 11:24:39 +0200
> >David Brown <david.brown@hesbynett.no> wrote:
> >> As long as the results are the same for any possible values of the 
> >> variables for which there are no signed overflows in original 
> >> expression, any order of evaluation is allowed.
> >
> >Rereading the posts I suspect there is a more basic misunderstanding
> >than with respect to some rather improbable applications of the
> >observable effects rule to calculations without side effects.
> >
> >Our Muttley appears to think that operator precedence determines the
> >order of evaluation of operands, which is wrong.  For example in the
> 
> Where did I say that?

This posting of 6 Apr 2022 15:00:29 is only reasonably explicable on
the basis that you think (or thought) that parentheses had an effect
on evaluation order of the operands: 

  "On Mon, 4 Apr 2022 12:02:44 +0200
  David Brown <david.brown@hesbynett.no> wrote:
  > On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
  >> Perhaps it should be defined as it looks reasonable to me. What does the
  >> standard say about i = (++i) + (++i) ?
  >> 
  >
  > The same thing - undefined behaviour.  Parentheses do not affect the 
  > order of evaluation.

  I don't understand why it should be undefined. It should evaluate both
  sides of the argument in order they're defined - and it has to be in
  order or precedance checks, lazy evaluation and function calls could
  fail ..."

Possibly you carry with you some other misunderstanding as well, who
knows.  But the effect of precedence on evaluation certainly seems to
be one of them.

[toc] | [prev] | [next] | [standalone]

#83501 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Wed, 6 Apr 2022 15:00:29 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
> On Wed, 6 Apr 2022 15:40:10 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
> >On Wed, 6 Apr 2022 11:24:39 +0200
> >David Brown <david.brown@hesbynett.no> wrote:
> >> As long as the results are the same for any possible values of the 
> >> variables for which there are no signed overflows in original 
> >> expression, any order of evaluation is allowed.
> >
> >Rereading the posts I suspect there is a more basic misunderstanding
> >than with respect to some rather improbable applications of the
> >observable effects rule to calculations without side effects.
> >
> >Our Muttley appears to think that operator precedence determines the
> >order of evaluation of operands, which is wrong.  For example in the
> 
> Where did I say that?

This posting of 6 Apr 2022 15:00:29 is only reasonably explicable on
                ^^^^^^^^^^^^^^^^^^^
Correction:     4 Apr 2022 14:42:05


the basis that you think (or thought) that parentheses had an effect
on evaluation order of the operands: 

  "On Mon, 4 Apr 2022 12:02:44 +0200
  David Brown <david.brown@hesbynett.no> wrote:
  > On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
  >> Perhaps it should be defined as it looks reasonable to me. What does the
  >> standard say about i = (++i) + (++i) ?
  >> 
  >
  > The same thing - undefined behaviour.  Parentheses do not affect the 
  > order of evaluation.

  I don't understand why it should be undefined. It should evaluate both
  sides of the argument in order they're defined - and it has to be in
  order or precedance checks, lazy evaluation and function calls could
  fail ..."

Possibly you carry with you some other misunderstanding as well, who
knows.  But the effect of precedence on evaluation certainly seems to
be one of them.

[toc] | [prev] | [next] | [standalone]

#83518 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Wed, 6 Apr 2022 17:03:49 +0100
Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>On Wed, 6 Apr 2022 15:00:29 -0000 (UTC)
>Muttley@dastardlyhq.com wrote:
>> On Wed, 6 Apr 2022 15:40:10 +0100
>> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
>> >On Wed, 6 Apr 2022 11:24:39 +0200
>> >David Brown <david.brown@hesbynett.no> wrote:
>> >> As long as the results are the same for any possible values of the 
>> >> variables for which there are no signed overflows in original 
>> >> expression, any order of evaluation is allowed.
>> >
>> >Rereading the posts I suspect there is a more basic misunderstanding
>> >than with respect to some rather improbable applications of the
>> >observable effects rule to calculations without side effects.
>> >
>> >Our Muttley appears to think that operator precedence determines the
>> >order of evaluation of operands, which is wrong.  For example in the
>> 
>> Where did I say that?
>
>This posting of 6 Apr 2022 15:00:29 is only reasonably explicable on
>the basis that you think (or thought) that parentheses had an effect
>on evaluation order of the operands: 
>
>  "On Mon, 4 Apr 2022 12:02:44 +0200
>  David Brown <david.brown@hesbynett.no> wrote:
>  > On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
>  >> Perhaps it should be defined as it looks reasonable to me. What does the
>  >> standard say about i = (++i) + (++i) ?
>  >> 
>  >
>  > The same thing - undefined behaviour.  Parentheses do not affect the 
>  > order of evaluation.
>
>  I don't understand why it should be undefined. It should evaluate both
>  sides of the argument in order they're defined - and it has to be in
>  order or precedance checks, lazy evaluation and function calls could
>  fail ..."
>
>Possibly you carry with you some other misunderstanding as well, who
>knows.  But the effect of precedence on evaluation certainly seems to
>be one of them.

You're reading between the lines and coming up with 1+1 = 3.

[toc] | [prev] | [next] | [standalone]

#83523 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/7/22 04:58, Muttley@dastardlyhq.com wrote:
> On Wed, 6 Apr 2022 17:03:49 +0100
> Chris Vine <chris@cvine--nospam--.freeserve.co.uk> wrote:
...
>> This posting of 6 Apr 2022 15:00:29 is only reasonably explicable on
>> the basis that you think (or thought) that parentheses had an effect
>> on evaluation order of the operands:
>> "On Mon, 4 Apr 2022 12:02:44 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
>>>> Perhaps it should be defined as it looks reasonable to me. What
>> does the
>>>> standard say about i = (++i) + (++i) ?
>>> The same thing - undefined behaviour. Parentheses do not affect the
>>> order of evaluation.
>>
>> I don't understand why it should be undefined. It should evaluate both
>> sides of the argument in order they're defined - and it has to be in
>> order or precedance checks, lazy evaluation and function calls could
>> fail ..."
>>
>> Possibly you carry with you some other misunderstanding as well, who
>> knows. But the effect of precedence on evaluation certainly seems to
>> be one of them.
>
> You're reading between the lines and coming up with 1+1 = 3.

OK, then what did you mean when you said that "it should evaluate both
sides of the argument in the order they're defined"? Let me break that
down into several sub-questions:
1. What is this "argument" you referred to? The standard doesn't refer
to any part of `i = (++i) + (++i)` as an argument. I've been assuming
that you're referring to the binary addition expression.
2. What are the two sides that you're referring to? The binary +
operator has two operands, one on each side of it, so I assumed that's
what you were talking about.
3. What do you mean by "the order they're defined"? Nothing is defined
in that expression, so I assumed you meant the order in which they are
mentioned.

If you were asserting that the two (++i) expressions should be evaluated
in the order in which they are mentioned in the addition expression,
then 6.9.1p10 says you're wrong. If that's not what you meant, what did
you mean?

[toc] | [prev] | [next] | [standalone]

#83506 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 6 Apr 2022 11:24, David Brown wrote:
> [snip]
> 
> Given "a * (b + c)", the compiler might choose to evaluate "a * b", "a * 
> c", then add them together, if it has knowledge of the values that make 
> that more efficient (perhaps such re-ordering would let it use smaller 
> width multiplication instructions).  It could also re-order "(a * b) + 
> (a * c)" into "a * (b + c)" if that made more sense.

No.

The compiler can only reorder if it can prove that in all executions the 
result will be the same.

I.e. one can rely on the "as if" the parenthesis is strictly honored.

Example (can be scaled to work as a signed `int` example also):

    const double a = 1.5;
    const double b = DBL_MAX;
    const double c = -DBL_MAX/2;

    a*(b + c);  // OK
    a*b + a*c;  //! Gah, overflow in first term.


> As long as the results are the same for any possible values of the 
> variables for which there are no signed overflows in original 
> expression, any order of evaluation is allowed.

Yes, modulo kind of overflow, underflow, sign preservation etc.

- Alf

[toc] | [prev] | [next] | [standalone]

#83517 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 06/04/2022 23:13, Alf P. Steinbach wrote:
> On 6 Apr 2022 11:24, David Brown wrote:
>> [snip]
>>
>> Given "a * (b + c)", the compiler might choose to evaluate "a * b", "a 
>> * c", then add them together, if it has knowledge of the values that 
>> make that more efficient (perhaps such re-ordering would let it use 
>> smaller width multiplication instructions).  It could also re-order 
>> "(a * b) + (a * c)" into "a * (b + c)" if that made more sense.
> 
> No.
> 

Yes.

> The compiler can only reorder if it can prove that in all executions the 
> result will be the same.
> 

Yes - that's what I wrote.  "As long as the results are the same".  The 
results (as they affect observable behaviour) must be the same, for all 
/possible/ values of the parts of the expression.

> I.e. one can rely on the "as if" the parenthesis is strictly honored.
> 

Of course.  You are saying the same thing as I did, but with different 
words.  (Perhaps that's not a bad thing and will help Muttley understand.)

Look, this is all pretty obvious.  No one is suggesting that the 
compiler can manipulate things at will to give /different/ results!

[toc] | [prev] | [next] | [standalone]

#83503 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/5/2022 8:54 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 5 Apr 2022 08:37:23 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/5/2022 8:18 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 08:49:18 -0700
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>> On 4/4/2022 7:42 AM, Muttley@dastardlyhq.com wrote:
>>>>> On Mon, 4 Apr 2022 12:02:44 +0200
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
>>>>>>> Perhaps it should be defined as it looks reasonable to me. What does the
>>>>>>> standard say about i = (++i) + (++i) ?
>>>>>>>
>>>>>>
>>>>>> The same thing - undefined behaviour.  Parentheses do not affect the
>>>>>> order of evaluation.
>>>>>
>>>>> I don't understand why it should be undefined. It should evaluate both
>> sides
>>>>> of the argument in order they're defined - and it has to be in order or
>>>>> precedance checks, lazy evaluation and function calls could fail - and then
>>
>>>> do
>>>>> the addition. So if i = 1 at the start then at the end it should be 2 + 3.
>>>>
>>>> That's a lot of "should" and "has to be" with no connection to reality.
>>>>
>>>> C and C++ don't work that way. Precedence in C and C++ has no relation
>>>> to order of evaluation for built-in operators.
>>>
>>> Really? So if I write a + b * c it might evaluate a + b first? You sure
>>> about that?
>>>
>>
>> Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one
>> knows what it will evaluate first and how it will evaluate it.
> 
> And why would it evaluate a+b when the result would be thrown away unless
> 'c' happened to be 1? Is this some special compiler guaranteed to produce the
> least efficient binary possible?

Who knows or cares? There could be millions of different reasons for that.

A compiler could decide to evaluate

   a + b * c

as

   (a + b) * c - a * (c - 1)

simply because it just happened to have both `(a + b) * c` and `a * (c - 
1)` readily available from some previous (unrelated) evaluation. And it 
is confident that the result will not be distorted by the replacement of 
the former with the latter.

First and foremost, this is illustrates the fact that discussing 
evaluation of out-of-context expressions in a language fundamentally 
governed by the "AS IF" rule is a pointless exercise.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83505 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/5/22 11:54, Muttley@dastardlyhq.com wrote:
> On Tue, 5 Apr 2022 08:37:23 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/5/2022 8:18 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 08:49:18 -0700
>>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>>> On 4/4/2022 7:42 AM, Muttley@dastardlyhq.com wrote:
>>>>> On Mon, 4 Apr 2022 12:02:44 +0200
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote:
>>>>>>> Perhaps it should be defined as it looks reasonable to me. What does the
>>>>>>> standard say about i = (++i) + (++i) ?
>>>>>>>
>>>>>>
>>>>>> The same thing - undefined behaviour.  Parentheses do not affect the
>>>>>> order of evaluation.
>>>>>
>>>>> I don't understand why it should be undefined. It should evaluate both
>> sides
>>>>> of the argument in order they're defined - and it has to be in order or
>>>>> precedance checks, lazy evaluation and function calls could fail - and then

Since you've denied making any such comment, I'd like to point out the
above as the place where you suggest that the order of evaluation is
determined by "the order they're defined" and "precedence".

If you think that the first ++i must be evaluated before the second ++i,
just because it's "defined first", then you've made the mistake that
people have been accusing you of.

>>>> do
>>>>> the addition. So if i = 1 at the start then at the end it should be 2 + 3.
>>>>
>>>> That's a lot of "should" and "has to be" with no connection to reality.
>>>>
>>>> C and C++ don't work that way. Precedence in C and C++ has no relation
>>>> to order of evaluation for built-in operators.

That is an exaggeration. While not defined in terms of precedence, in
many contexts the grammar of C and C++ conveys the same information that
could also have been conveyed by an operator precedence table (and in
others, it conveys information that could not be explained solely by
operator precedence).
The C and C++ grammars definitely do constrain the order of evaluation,
but they do not determine it. In particular, the two ++i expressions are
unambiguously unsequenced.

>>> Really? So if I write a + b * c it might evaluate a + b first? You sure
>>> about that?
>>>
>>
>> Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one 
>> knows what it will evaluate first and how it will evaluate it.
> 
> And why would it evaluate a+b when the result would be thrown away unless
> 'c' happened to be 1? Is this some special compiler guaranteed to produce the 
> least efficient binary possible?

I'd recommend ignoring Andrey's answer. While technically correct, it's
correct only in the sense the the compiler is free to generate code
which does anything it wants to do, so long as it makes sure that
there's no resulting "observable behavior", as that term is defined in
4.1p6. That definition is very definitely NOT the same as "behavior
which is observable". It must, in addition to doing whatever it wants to
do with no observable consequences, also perform the specified
calculation (at least, if there are any observable consequences of
performing that calculation correctly), and I'm sure you were only
referring to how it handles that calculation. Andrey's answer doesn't
address that point.

A conforming implementation of C++ has to evaluate b and c before
evaluating b*c, but those two evaluations are unsequenced. It must
evaluate a and b*c before evaluating a + b*c, but the evaluation of a
and the evaluation of b*c are unsequenced. As a consequence, the
evaluation of a is also unsequenced relative to the evaluations of b and c.

I hope that makes it clear how operator precedence constrains the order
of evaluation, but does not determine it.

[toc] | [prev] | [next] | [standalone]

#83507 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 06/04/2022 19:50, James Kuyper wrote:
>
> If you think that the first ++i must be evaluated before the second ++i,
> just because it's "defined first", then you've made the mistake that
> people have been accusing you of.


Perhaps the accusation may not be justified because there are times you 
want to know that the order will be preserved. For example, if you have 
a function like so:

string BinaryString(int Number)
{
     if (Number == 0)
     {
         return "0";
     }
     else
         if (Number == 1)
         {
             return "1";
         }
         else
         {
             return (BinaryString(Number / 2) + BinaryString(Number % 2));
         }

     return "0";
}

Now if you run the following program then the final result is very 
important:

int main(void)
{
     cout << BinaryString(100) << endl;

     return EXIT_SUCCESS;
}

[toc] | [prev] | [next] | [standalone]

#83508 — Re: GCC hasn't even gotten around to sequencing argument evaluation

Sams Lara <samlara622@gmail.com> writes:
[...]
> string BinaryString(int Number)
> {
>    if (Number == 0)
>    {
[snip]

Maybe this doesn't affect anyone else, but there's something odd about
the way your post is encoded.  It appears to be Latin-1 with NO-BREAK
SPACE characters.  In my newsreader (Gnus), the above looks like this:

> string BinaryString(int Number)
> {
>  \240\240\240 if (Number == 0)
>  \240\240\240 {

where \240 is the octal encoding of NO-BREAK SPACE.

Can you configure your news software to use UTF-8 and/or avoid NO-BREAK
SPACE characters?

Thanks.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#83509 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 06/04/2022 22:51, Keith Thompson wrote:
>
> Can you configure your news software to use UTF-8 and/or avoid NO-BREAK
> SPACE characters?
OK try this:

string BinaryString(int Number)
{
      if (Number == 0)
      {
          return "0";
      }
      else
          if (Number == 1)
          {
              return "1";
          }
          else
          {
              return (BinaryString(Number / 2) + BinaryString(Number % 2));
          }

      return "0";
}

Now if you run the following program then the final result is very
important:

int main(void)
{
      cout << BinaryString(100) << endl;

      return EXIT_SUCCESS;
}

I was simply saying that the final return in the function like so will give wrong result:
// return (BinaryString(Number % 2) + BinaryString(Number / 2));

The order is changed in the parameter.

[toc] | [prev] | [next] | [standalone]

#83512 — Re: GCC hasn't even gotten around to sequencing argument evaluation

Sams Lara <samlara622@gmail.com> writes:
> On 06/04/2022 22:51, Keith Thompson wrote:
>>
>> Can you configure your news software to use UTF-8 and/or avoid NO-BREAK
>> SPACE characters?
> OK try this:
>
> string BinaryString(int Number)
> {
>      if (Number == 0)
>      {
>          return "0";
>      }
>      else
[snip]

That looks better in my newsreader.

I'll note that you still have NO-BREAK SPACE characters, but now my
newsreader can figure out how to display.  But if I save the article
to a source file, gcc complains about stray '\240' characters.

You have this in your article headers:
Content-Type: text/plain; charset=windows-1252; format=flowed

I still recommend using UTF-8 and avoiding NO-BREAK SPACE characters,
but I'm not going to worry about it.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#83510 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On Thursday, 7 April 2022 at 00:34:23 UTC+3, Sams Lara wrote:
> On 06/04/2022 19:50, James Kuyper wrote: 
> > 
> > If you think that the first ++i must be evaluated before the second ++i, 
> > just because it's "defined first", then you've made the mistake that 
> > people have been accusing you of.
> Perhaps the accusation may not be justified because there are times you 
> want to know that the order will be preserved. For example, if you have 
> a function like so: 
> 
> string BinaryString(int Number) 
> { 
>     if (Number == 0) 
>     { 
>         return "0"; 
>     } 

Note that else after if that returns or throws is  superfluous:

>     else 
>         if (Number == 1) 
>         { 
>             return "1"; 
>         } 

Here too excessive else:

>         else 
>         { 
>             return (BinaryString(Number / 2) + BinaryString(Number % 2)); 
>         } 

Unreachable return. Would be obvious without redundant elses:

> 
>     return "0"; 
> } 
> 
> Now if you run the following program then the final result is very 
> important: 
> 
> int main(void) 
> { 
>     cout << BinaryString(100) << endl; 
> 
>     return EXIT_SUCCESS; 
> }

[toc] | [prev] | [next] | [standalone]

#83548 — Re: GCC hasn't even gotten around to sequencing argument evaluation

Tiib <ootiib@hot.ee> writes:

> On Thursday, 7 April 2022 at 00:34:23 UTC+3, Sams Lara wrote:
>
>> On 06/04/2022 19:50, James Kuyper wrote:
>>
>>> If you think that the first ++i must be evaluated before the
>>> second ++i, just because it's "defined first", then you've made
>>> the mistake that people have been accusing you of.
>>
>> Perhaps the accusation may not be justified because there are times
>> you want to know that the order will be preserved.  For example, if
>> you have a function like so:
>>
>> string BinaryString(int Number)
>> {
>>     if (Number == 0)
>>     {
>>         return "0";
>>     }
>
> Note that else after if that returns or throws is  superfluous:
>
>>     else
>>         if (Number == 1)
>>         {
>>             return "1";
>>         }
>
> Here too excessive else:
>
>>         else
>>         {
>>             return (BinaryString(Number / 2) + BinaryString(Number % 2));
>>         }
>
> Unreachable return.  Would be obvious without redundant elses:

Better to get rid of all those pesky if() statements and just use
one return (disclaimer: not compiled):

    string
    BinaryString( const int N ){
        return
             N == 0  ?  "0"
          :  N == 1  ?  "1"
          :  BinaryString( N *1u /2 ) + BinaryString( N *1u %2 );
    }

(Note:  the 1u factors in the last line are there to avoid a
nasty bug when N is negative.)

[toc] | [prev] | [next] | [standalone]

#83515 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/6/22 17:27, Sams Lara wrote:
> On 06/04/2022 19:50, James Kuyper wrote:
>>
>> If you think that the first ++i must be evaluated before the second ++i,
>> just because it's "defined first", then you've made the mistake that
>> people have been accusing you of>
>
> Perhaps the accusation may not be justified because there are times
> you want to know that the order will be preserved.

When you need to know that two expressions will be evaluated in a
particular order, then C++ provides many options for guaranteeing that.
The simplest is to evaluate those expressions in different statements.

Making them sub-expressions of the same expression is NOT one of those
ways, unless otherwise specified in the description of the relevant
operator. It is otherwise specified for many operators, but binary +
isn't one of them.

> For example, if you have a function like so:
>
> string BinaryString(int Number)
> {
>     if (Number == 0)
>     {
>         return "0";
>     }
>     else
>         if (Number == 1)
>         {
>             return "1";
>         }
>         else
>         {
>             return (BinaryString(Number / 2) + BinaryString(Number % 2));

I had no idea when you first posted this why you thought order of
evaluation was important to this program. However, in a later message
you indicated that it's this line whose order of evaluation you're
thinking of. There's two different orders of evaluation that are
permitted by the standard:

The first order is equivalent to:
temp1 = BinaryString(Number/2);
temp2 = BinaryString(Number%2):
return temp1 + temp2;

The second order is equivalent to:
temp2 = BinaryString(Number%2):
temp1 = BinaryString(Number/2);
return temp1 + temp2;

Both orders of evaluation return the same result.

There are contexts where this wouldn't be true, for instance if
BinaryString() wrote something to an object with static or thread-local
storage duration. For precisely that reason, you shouldn't write such
code and call it like this if the order in which the functions are
evaluated matters - because that order is not specified by the C++ standard.

[toc] | [prev] | [next] | [standalone]

#83514 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/6/2022 11:50 AM, James Kuyper wrote:
>>>
>>> Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one
>>> knows what it will evaluate first and how it will evaluate it.
>>
>> And why would it evaluate a+b when the result would be thrown away unless
>> 'c' happened to be 1? Is this some special compiler guaranteed to produce the
>> least efficient binary possible?
> 
> I'd recommend ignoring Andrey's answer. While technically correct, it's
> correct only in the sense the the compiler is free to generate code
> which does anything it wants to do, so long as it makes sure that
> there's no resulting "observable behavior", as that term is defined in
> 4.1p6. That definition is very definitely NOT the same as "behavior
> which is observable". It must, in addition to doing whatever it wants to
> do with no observable consequences, also perform the specified
> calculation (at least, if there are any observable consequences of
> performing that calculation correctly), and I'm sure you were only
> referring to how it handles that calculation. Andrey's answer doesn't
> address that point.


I'm going to have to override this recommendation (what I usually call 
"to pull the rank"). My answer stands unchanged.

As usual on Usenet (and Internet in general) the matter quickly gets out 
of hands and spills out of the boundaries of the original topic, which 
is what happened here. I would normally just ignore such chaff, but in 
this case I just have to remark on the fact that what this topic 
demonstrates is how many members here lack understanding of what the 
language standard actually is, what it defines and how it actually "works".

The fundamental axiom that you need to grasp in order to even start 
developing that understanding is the fact the standard never imposes any 
direct behavioral requirements upon the implementations. When it comes 
to defining a conforming program's behavior the standard connects to 
implementations in a very indirect way, that can be outlined in the 
following three steps:

   1. The Standard defines the behavior of an imaginary Abstract C++ 
Machine and only of Abstract C++ Machine

   2. The Abstract C++ Machine, when fed in program P, determines the 
conforming observable behavior of that program P, or a 
multitude/variety/range/set of conforming observable behaviors

   3. A conforming implementation can translate the program P in any way 
it pleases, but it has to make sure that the resultant observable 
behavior of P falls into the range of observable behavior defined at step 2

That's all. That is what the language standard is and that is how it 
"works" when it comes to program's behavior.

Never ever anywhere in the standard text it makes an attempt to impose 
any localized behavioral requirements directly onto the actual 
implementations, like imposing a specific order of evaluation for an 
expression. The connection between the standard and the implementations 
exists, but only in a very very VERY circuitous way shown above. Every 
time you see the standard seemingly making a specific behavioral 
requirement directed at the implementations, it is really a just 
_shorthand_, a compact way of referring to the above long and roundabout 
relationship.

For some reason, despite all efforts of C++ community, many people have 
hard time grasping this concept. And it shows. This misunderstanding is 
the source of bizarre claims and expectations, like expecting operator 
precedence and associativity define/determine the order of evaluation in 
actual programs. (Even if you wanted to insist on it, it would still 
apply to imaginary Abstract C++ Machine only, not to the actual 
real-life implementations.)

P.S. There are other requirements imposed by the standard upon 
implementations, like issuing a diagnostic when one's required, and 
other auxiliary/utilitarian matters. Above I'm talking about conforming 
program's behavioral requirements only.

-- 
Best regards,
Andrey Tarasevich

[toc] | [prev] | [next] | [standalone]

#83516 — Re: GCC hasn't even gotten around to sequencing argument evaluation

On 4/6/22 21:39, Andrey Tarasevich wrote:
...
> 1. The Standard defines the behavior of an imaginary Abstract C++
> Machine and only of Abstract C++ Machine
>
> 2. The Abstract C++ Machine, when fed in program P, determines the
> conforming observable behavior of that program P, or a
> multitude/variety/range/set of conforming observable behaviors
>
> 3. A conforming implementation can translate the program P in any way
> it pleases, but it has to make sure that the resultant observable
> behavior of P falls into the range of observable behavior defined at
> step 2
>
> That's all. That is what the language standard is and that is how it
> "works" when it comes to program's behavior.
>
> Never ever anywhere in the standard text it makes an attempt to impose
> any localized behavioral requirements directly onto the actual
> implementations, like imposing a specific order of evaluation for an
> expression. 
Then what precisely do the standard-defined terms "sequenced before",
"unsequenced" and indeterminately sequenced" mean to you?
To me, they mean that the program must produce the same result as if all
things that are sequenced relative to each other occur in an order
consistent with those sequencing relationships. They don't have to
actually occur in such an order, but that fact is important only for
thinking about optimization possibilities. When thinking about what the
required observable behavior of the program actually is, by far the
easiest way to do it is to think about things actually occurring in an
order consistent with those sequencing requirements.

> the source of bizarre claims and expectations, like expecting operator
> precedence and associativity define/determine the order of evaluation
> in actual programs. (Even if you wanted to insist on it, it would
> still apply to imaginary Abstract C++ Machine only, not to the actual
> real-life implementations.)

Operator precedence and associativity don't determine the order of
evaluation, but they do constrain it. Those things determine which
expressions are operands of any given operator, and "The value
computations of the operands of an operator are sequenced before the
value computation of the result of the operator." (6.9.1p10). That only
applies to the abstract machine, but it's precisely the sequences
allowed for the abstract machine that determine what observable behavior
is permitted to a program.

Keep in mind that the permitted observable behavior is, ultimately, the
key thing we're discussing. The fact that the increments in `i = (++i) +
(++i)` are unsequenced relative to each other means that the standard
imposes no requirements on the observable behavior of the program. If
that problem had been avoided, there would have been much stronger
requirements on the observable behavior.

[toc] | [prev] | [next] | [standalone]

Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

Back to top | Article view | comp.lang.c++

csiph-web