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

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

Started by	Andrey Tarasevich <andreytarasevich@hotmail.com>
First post	2022-04-01 20:34 -0700
Last post	2022-04-11 15:11 -0700
Articles	20 on this page of 121 — 25 participants

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

  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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →

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

From	scott@slp53.sl.home (Scott Lurndal)
Date	2022-04-04 17:59 +0000
Subject	Re: GCC hasn't even gotten around to sequencing argument evaluation
Message-ID	<LlG2K.22429$e%.17341@fx36.iad>
In reply to	#83469

David Brown <david.brown@hesbynett.no> writes:
>On 04/04/2022 15:01, Malcolm McLean wrote:
>> On Monday, 4 April 2022 at 12:29:00 UTC+1, David Brown wrote:

>> If you wrap, you do not raise a signal. Generally this is cheaper than raising
>> a signal because wrapping requires less circuitry than detecting overflow
>> and raising  a signal. You've got it the wrong way round. Now if I was 
>> arrongant and patronising like you, I'd say something arrrogant and
>> patronising at this point.  

"cheaper than raising a signal".  Not really.  Setting the condition
flags in the ALU is basically a side effect of normal ALU operation.  They're
always set.   Not all instructions (e.g. on ARM) will commit them to
the architectural flags register (e.g. ARMv8 PSTATE), that depends on the
instruction definition which allows the compiler to choose whether or
not an ALU operation updates the programmer visible condition flags.

Causing a floating point exception requires a single additional FF for the enable bit.

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

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

From	Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Date	2022-04-05 06:55 -0700
Subject	Re: GCC hasn't even gotten around to sequencing argument evaluation
Message-ID	<d2d1b655-4b40-43a4-9730-883601df7b5fn@googlegroups.com>
In reply to	#83470

On Monday, 4 April 2022 at 18:59:23 UTC+1, Scott Lurndal wrote:
> David Brown <david...@hesbynett.no> writes: 
> >On 04/04/2022 15:01, Malcolm McLean wrote: 
> >> On Monday, 4 April 2022 at 12:29:00 UTC+1, David Brown wrote: 
> 
> >> If you wrap, you do not raise a signal. Generally this is cheaper than raising 
> >> a signal because wrapping requires less circuitry than detecting overflow 
> >> and raising a signal. You've got it the wrong way round. Now if I was 
> >> arrongant and patronising like you, I'd say something arrrogant and 
> >> patronising at this point.
> "cheaper than raising a signal". Not really. Setting the condition 
> flags in the ALU is basically a side effect of normal ALU operation. They're 
> always set. Not all instructions (e.g. on ARM) will commit them to 
> the architectural flags register (e.g. ARMv8 PSTATE), that depends on the 
> instruction definition which allows the compiler to choose whether or 
> not an ALU operation updates the programmer visible condition flags. 
> 
> Causing a floating point exception requires a single additional FF for the enable bit.
>
There's quite a bit of circuitry there to detect the floating point exception, and then
handle the exception in some fashion, like sending out an IRQ.
It would be possible to engineer a processor which has a concept of "signed
integer registers", and raises a similar signal on signed arithmetical overflow.
This isn't usually done because of the expense.
There is often  a "carry flag" or a "high result register" which can be read by normal 
machine instructions  and used to detect signed overflow that way. But that involves 
extra logic after each signed arithmetic instruction. 

That's why the normal behaviour is to wrap on signed arithmetic overflow.

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

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

From	Manfred <noname@add.invalid>
Date	2022-04-03 18:39 +0200
Subject	Re: GCC hasn't even gotten around to sequencing argument evaluation
Message-ID	<t2cikc$tq2$1@gioia.aioe.org>
In reply to	#83430

On 4/3/2022 1:02 PM, David Brown wrote:
> (And no, despite some people's misunderstandings, this is not due to
> overly-enthusiastic optimising compilers or flaws in the language - it
> is fundamental to all programming, and fundamental to any kind of error
> or mistake in the code.  Different compilers, languages, and programming
> styles can influence how the risks build up, but not the principles.)

This is technically true, but I believe there is more to it.

In the early days, when a C compiler would effectively be a glorified 
assembler, a C++ compiler would effectively be a glorified C compiler, 
and processors and architectures were much simpler than today, one could 
argue that the compiler would do the "sensible thing" with some code 
construct, even if slightly licentious.

This scenario still has some appeal to programmers, because it gives the 
impression of being in direct control of the final program - I remember 
a video where Alexander Stepanov was praising C++ because you could see 
the bits flowing in code (!)

https://youtu.be/-n8FP7Ncq8A

Nowadays' truth is more complicated than that. Compilers have become 
more complex and performing, processors have evolved, and source code 
has gotten more and more decoupled from compiled binary code.
This obviously poses much harder requirements on formal consistency of 
languages and standards - a glorified assembler could count on the 
ultimate authority of the ASM instruction set specification, a modern 
compiler just can't.

This explains the effort of the standard to get more and more detailed 
in the specification of the language - it is also a significant 
challenge for its evolution, since 1300+ pages of standardese were 
already difficult enough to manage for C++11, yet C++17 got to 1600+, 
and C++20 exceeds 1800.
Remember the Vasa!

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

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

From	Paavo Helde <eesnimi@osa.pri.ee>
Date	2022-04-03 09:09 +0300
Subject	Re: GCC hasn't even gotten around to sequencing argument evaluation
Message-ID	<t2bdna$2lv$1@dont-email.me>
In reply to	#83414

02.04.2022 17:28 Muttley@dastardlyhq.com kirjutas:
> On Sat, 2 Apr 2022 14:12:17 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> It seems gcc has handled this as:
>>
>> 	++i;
>> 	++i;
>> 	a = i;
>> 	b = i;
>>
>> and AFAIUI, this interleaving is not allowed in C++17.
>>
>> Prior to C++17, the code could do anything - segfault, return 42, buy
>> you flowers - whatever it liked.
> 
> Why would it segfault? Its simply incrementing values albeit in an
> indeterminate order.

In practice, killing the program at spot by an assert failure is not so 
different from a segfault. And this is exactly what you get for some 
kind of UB, for example for signed integer overflow with relevant gcc 
compiler flags. Such behavior is perfectly conforming, because UB means UB.

Some people have argued blue in face that such things cannot happen and 
may not happen, even after I shown them exactly how this happens. Is the 
C++ implementation conforming? Yes, it is. Is the program killed on spot 
when it runs? Yes, it is. Was it your fault as a programmer to write 
code containing UB? Yes, it was.

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

#83419

From	Manfred <noname@add.invalid>
Date	2022-04-02 19:53 +0200
Message-ID	<t2a2j1$j43$1@gioia.aioe.org>
In reply to	#83411

On 4/2/2022 2:12 PM, David Brown wrote:
> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>
>>>       int r = foo(++i, ++i);
>>
>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>> and a very important change in C++17. How come it is still not
>>> implemented in GCC? What are they waiting for? Is there some sort of
>>> intentional opposition to that change in the standard?
>>
>> I'm not an expert on the standard, but according to this page:
>> https://en.cppreference.com/w/cpp/language/eval_order
>>
>> it is not specified. They have exactly your example down the page:
>>
>> f(++i, ++i);
>> // undefined behavior until C++17, unspecified after C++17
>>
>> To me that sounds like before C+17, the program could segfault, whereas
>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>
>> Am I wrong?
>>
>>      Christian
> 
> The "unspecified" aspect refers to the ordering of evaluation of the
> parameters - they are "indeterminately ordered".
> 
> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
> 
> 	a = ++i;
> 	b = ++i;
> 	foo(a, b);
> 
> or
> 
> 	b = ++i;
> 	a = ++i;
> 	foo(a, b);
> 
> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
> respectively.  But their sum will be the same.
> 
> It seems gcc has handled this as:
> 
> 	++i;
> 	++i;
> 	a = i;
> 	b = i;
> 
> and AFAIUI, this interleaving is not allowed in C++17.
> 
> Prior to C++17, the code could do anything - segfault, return 42, buy
> you flowers - whatever it liked.
> 

Doesn't the sentence "undefined behavior until C++17, unspecified after 
C++17" mean that it actually got defined behavior (albeit unspecified) 
/after/ C++ 17?
So that up to and /including/ C++ 17 it is UB?

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

#83431

From	David Brown <david.brown@hesbynett.no>
Date	2022-04-03 13:45 +0200
Message-ID	<t2c1c0$fvr$1@dont-email.me>
In reply to	#83419

On 02/04/2022 19:53, Manfred wrote:
> On 4/2/2022 2:12 PM, David Brown wrote:
>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>
>>>>       int r = foo(++i, ++i);
>>>
>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>> and a very important change in C++17. How come it is still not
>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>> intentional opposition to that change in the standard?
>>>
>>> I'm not an expert on the standard, but according to this page:
>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>
>>> it is not specified. They have exactly your example down the page:
>>>
>>> f(++i, ++i);
>>> // undefined behavior until C++17, unspecified after C++17
>>>
>>> To me that sounds like before C+17, the program could segfault, whereas
>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>
>>> Am I wrong?
>>>
>>>      Christian
>>
>> The "unspecified" aspect refers to the ordering of evaluation of the
>> parameters - they are "indeterminately ordered".
>>
>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be
>> either:
>>
>>     a = ++i;
>>     b = ++i;
>>     foo(a, b);
>>
>> or
>>
>>     b = ++i;
>>     a = ++i;
>>     foo(a, b);
>>
>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>> respectively.  But their sum will be the same.
>>
>> It seems gcc has handled this as:
>>
>>     ++i;
>>     ++i;
>>     a = i;
>>     b = i;
>>
>> and AFAIUI, this interleaving is not allowed in C++17.
>>
>> Prior to C++17, the code could do anything - segfault, return 42, buy
>> you flowers - whatever it liked.
>>
> 
> Doesn't the sentence "undefined behavior until C++17, unspecified after
> C++17" mean that it actually got defined behavior (albeit unspecified)
> /after/ C++ 17?
> So that up to and /including/ C++ 17 it is UB?

You can argue that the text is not very precise.  But it means that for
code compiled with a compiler that is compliant to C++ standards prior
to C++17, this is undefined behaviour.  If the compiler is compliant to
C++17 or later, it is unspecified behaviour.

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

#83435

From	Manfred <noname@add.invalid>
Date	2022-04-03 17:27 +0200
Message-ID	<t2cec5$nvp$1@gioia.aioe.org>
In reply to	#83431

On 4/3/2022 1:45 PM, David Brown wrote:
> On 02/04/2022 19:53, Manfred wrote:
>> On 4/2/2022 2:12 PM, David Brown wrote:
>>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>>
>>>>>        int r = foo(++i, ++i);
>>>>
>>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>>> and a very important change in C++17. How come it is still not
>>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>>> intentional opposition to that change in the standard?
>>>>
>>>> I'm not an expert on the standard, but according to this page:
>>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>>
>>>> it is not specified. They have exactly your example down the page:
>>>>
>>>> f(++i, ++i);
>>>> // undefined behavior until C++17, unspecified after C++17
>>>>
>>>> To me that sounds like before C+17, the program could segfault, whereas
>>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>>
>>>> Am I wrong?
>>>>
>>>>       Christian
>>>
>>> The "unspecified" aspect refers to the ordering of evaluation of the
>>> parameters - they are "indeterminately ordered".
>>>
>>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be
>>> either:
>>>
>>>      a = ++i;
>>>      b = ++i;
>>>      foo(a, b);
>>>
>>> or
>>>
>>>      b = ++i;
>>>      a = ++i;
>>>      foo(a, b);
>>>
>>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>>> respectively.  But their sum will be the same.
>>>
>>> It seems gcc has handled this as:
>>>
>>>      ++i;
>>>      ++i;
>>>      a = i;
>>>      b = i;
>>>
>>> and AFAIUI, this interleaving is not allowed in C++17.
>>>
>>> Prior to C++17, the code could do anything - segfault, return 42, buy
>>> you flowers - whatever it liked.
>>>
>>
>> Doesn't the sentence "undefined behavior until C++17, unspecified after
>> C++17" mean that it actually got defined behavior (albeit unspecified)
>> /after/ C++ 17?
>> So that up to and /including/ C++ 17 it is UB?
> 
> You can argue that the text is not very precise.  But it means that for
> code compiled with a compiler that is compliant to C++ standards prior
> to C++17, this is undefined behaviour.  If the compiler is compliant to
> C++17 or later, it is unspecified behaviour.

Looking at the standard, yes. It's in fact the cppreference text that is 
not that precise.

BTW, gcc shows the same problem even with -std=c++20

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

#83422

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2022-04-02 21:17 +0100
Message-ID	<87wng7fdea.fsf@bsb.me.uk>
In reply to	#83411

David Brown <david.brown@hesbynett.no> writes:

> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>> 
>>>      int r = foo(++i, ++i);
>> 
>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>> and a very important change in C++17. How come it is still not
>>> implemented in GCC? What are they waiting for? Is there some sort of
>>> intentional opposition to that change in the standard?
>> 
>> I'm not an expert on the standard, but according to this page:
>> https://en.cppreference.com/w/cpp/language/eval_order
>> 
>> it is not specified. They have exactly your example down the page:
>> 
>> f(++i, ++i);
>> // undefined behavior until C++17, unspecified after C++17
>> 
>> To me that sounds like before C+17, the program could segfault, whereas
>> with C++17, it can either output 5 or 6, but shold consistently do so.
>> 
>> Am I wrong?
>> 
>>     Christian
>
> The "unspecified" aspect refers to the ordering of evaluation of the
> parameters - they are "indeterminately ordered".
>
> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
>
> 	a = ++i;
> 	b = ++i;
> 	foo(a, b);
>
> or
>
> 	b = ++i;
> 	a = ++i;
> 	foo(a, b);
>
> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
> respectively.  But their sum will be the same.
>
> It seems gcc has handled this as:
>
> 	++i;
> 	++i;
> 	a = i;
> 	b = i;
>
> and AFAIUI, this interleaving is not allowed in C++17.

I am not 100% sure.  The wording (C++20 but similar in C++17) is this:

  "The initialization of a parameter, including every associated value
  computation and side effect, is indeterminately sequenced with respect
  to that of any other parameter."

That sounds like the two ++i expressions need not to be thought of as
units with one sequenced before the other.  It sounds as if any
interleaving of the parts is permitted.  At least that's how I would
read it, unfamiliar as I am with the way the C++ authors use language.

(My reading would be the obvious one, I think, had they written "with
respect to /those/ of any other parameter" but I'm not I want to rely on
a that/those distinction for this.)

Also, there's a note which would seem almost redundant otherwise:

  "[Note: All side effects of argument evaluations are sequenced before
  the function is entered (see 6.9.1). — end note]

-- 
Ben.

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

#83424

From	Manfred <noname@invalid.add>
Date	2022-04-02 23:04 +0200
Message-ID	<t2ado5$1cut$1@gioia.aioe.org>
In reply to	#83422

On 4/2/22 10:17 PM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>
>>>>       int r = foo(++i, ++i);
>>>
>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>> and a very important change in C++17. How come it is still not
>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>> intentional opposition to that change in the standard?
>>>
>>> I'm not an expert on the standard, but according to this page:
>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>
>>> it is not specified. They have exactly your example down the page:
>>>
>>> f(++i, ++i);
>>> // undefined behavior until C++17, unspecified after C++17
>>>
>>> To me that sounds like before C+17, the program could segfault, whereas
>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>
>>> Am I wrong?
>>>
>>>      Christian
>>
>> The "unspecified" aspect refers to the ordering of evaluation of the
>> parameters - they are "indeterminately ordered".
>>
>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
>>
>> 	a = ++i;
>> 	b = ++i;
>> 	foo(a, b);
>>
>> or
>>
>> 	b = ++i;
>> 	a = ++i;
>> 	foo(a, b);
>>
>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>> respectively.  But their sum will be the same.
>>
>> It seems gcc has handled this as:
>>
>> 	++i;
>> 	++i;
>> 	a = i;
>> 	b = i;
>>
>> and AFAIUI, this interleaving is not allowed in C++17.
> 
> I am not 100% sure.  The wording (C++20 but similar in C++17) is this:
> 
>    "The initialization of a parameter, including every associated value
>    computation and side effect, is indeterminately sequenced with respect
>    to that of any other parameter."
> 
> That sounds like the two ++i expressions need not to be thought of as
> units with one sequenced before the other.  It sounds as if any
> interleaving of the parts is permitted.  At least that's how I would
> read it, unfamiliar as I am with the way the C++ authors use language.
> 
> (My reading would be the obvious one, I think, had they written "with
> respect to /those/ of any other parameter" but I'm not I want to rely on
> a that/those distinction for this.)

IIUC your distinction is about 'that' referred to initialization only, 
and 'those' that would be referred to initialization + value 
computations etc.
I think the wording is clear enough for the obvious meaning, though: 
they specify that initialization of a parameter is sequenced wrt that of 
any other parameter, but they also specify, in the subordinate, that 
initialization here includes every associated value computation and side 
effect.
This makes the meaning as in your 'those' version, unless I have 
misunderstood your point.

> 
> Also, there's a note which would seem almost redundant otherwise:
> 
>    "[Note: All side effects of argument evaluations are sequenced before
>    the function is entered (see 6.9.1). — end note]
> 

This is a note, which would be allowed to be redundant, but still it's 
about sequencing between argument evaluations and entering of the 
function, while the above is about sequencing of argument evaluations 
with each other. How would this be implied by the above?

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

#83425

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2022-04-03 00:22 +0100
Message-ID	<87a6d3f4v8.fsf@bsb.me.uk>
In reply to	#83424

Manfred <noname@invalid.add> writes:

> On 4/2/22 10:17 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>>
>>>>>       int r = foo(++i, ++i);
>>>>
>>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>>> and a very important change in C++17. How come it is still not
>>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>>> intentional opposition to that change in the standard?
>>>>
>>>> I'm not an expert on the standard, but according to this page:
>>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>>
>>>> it is not specified. They have exactly your example down the page:
>>>>
>>>> f(++i, ++i);
>>>> // undefined behavior until C++17, unspecified after C++17
>>>>
>>>> To me that sounds like before C+17, the program could segfault, whereas
>>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>>
>>>> Am I wrong?
>>>>
>>>>      Christian
>>>
>>> The "unspecified" aspect refers to the ordering of evaluation of the
>>> parameters - they are "indeterminately ordered".
>>>
>>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
>>>
>>> 	a = ++i;
>>> 	b = ++i;
>>> 	foo(a, b);
>>>
>>> or
>>>
>>> 	b = ++i;
>>> 	a = ++i;
>>> 	foo(a, b);
>>>
>>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>>> respectively.  But their sum will be the same.
>>>
>>> It seems gcc has handled this as:
>>>
>>> 	++i;
>>> 	++i;
>>> 	a = i;
>>> 	b = i;
>>>
>>> and AFAIUI, this interleaving is not allowed in C++17.
>> I am not 100% sure.  The wording (C++20 but similar in C++17) is this:
>>    "The initialization of a parameter, including every associated value
>>    computation and side effect, is indeterminately sequenced with respect
>>    to that of any other parameter."
>> That sounds like the two ++i expressions need not to be thought of as
>> units with one sequenced before the other.  It sounds as if any
>> interleaving of the parts is permitted.  At least that's how I would
>> read it, unfamiliar as I am with the way the C++ authors use
>> language.

Somewhat disappointingly I no longer think my reading is reasonable.
I've read that sentences 18 ways and, really, it does state that the
initialisation, value computations and side-effects are grouped, and it
is the groups that are indeterminately sequenced with respect to each
other.

I think I was seeing doubt here where there really isn't any.

-- 
Ben.

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

#83426

From	Andrey Tarasevich <andreytarasevich@hotmail.com>
Date	2022-04-02 17:33 -0700
Message-ID	<t2aq0o$1td$1@dont-email.me>
In reply to	#83422

On 4/2/2022 1:17 PM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>
>>>>       int r = foo(++i, ++i);
>>>
>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>> and a very important change in C++17. How come it is still not
>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>> intentional opposition to that change in the standard?
>>>
>>> I'm not an expert on the standard, but according to this page:
>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>
>>> it is not specified. They have exactly your example down the page:
>>>
>>> f(++i, ++i);
>>> // undefined behavior until C++17, unspecified after C++17
>>>
>>> To me that sounds like before C+17, the program could segfault, whereas
>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>
>>> Am I wrong?
>>>
>>>      Christian
>>
>> The "unspecified" aspect refers to the ordering of evaluation of the
>> parameters - they are "indeterminately ordered".
>>
>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
>>
>> 	a = ++i;
>> 	b = ++i;
>> 	foo(a, b);
>>
>> or
>>
>> 	b = ++i;
>> 	a = ++i;
>> 	foo(a, b);
>>
>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>> respectively.  But their sum will be the same.
>>
>> It seems gcc has handled this as:
>>
>> 	++i;
>> 	++i;
>> 	a = i;
>> 	b = i;
>>
>> and AFAIUI, this interleaving is not allowed in C++17.
> 
> I am not 100% sure.  The wording (C++20 but similar in C++17) is this:
> 
>    "The initialization of a parameter, including every associated value
>    computation and side effect, is indeterminately sequenced with respect
>    to that of any other parameter."
> 
> That sounds like the two ++i expressions need not to be thought of as
> units with one sequenced before the other.  It sounds as if any
> interleaving of the parts is permitted.  At least that's how I would
> read it, unfamiliar as I am with the way the C++ authors use language.
> 

No, "sequenced before" is a very strong requirement preventing any kind 
of interleaving.

The modern C++ sequencing terminology abandoned the idea of a "sequence 
point" and switched to some more finely attributed variants, which might 
refer to value computation and side-effects separately. One can say 
"value computation of the operand is sequenced before..." or 
"side-effects of the argument are sequenced after..."

But a plain unattributed "sequenced before (or after)" is basically the 
old-fashioned "sequence point": a full sequencing requirement that 
covers everything, i.e. the value computation and all side-effects together.

The quote you provided completely compartmentalizes and isolates 
argument expression evaluation and parameter initialization. No 
interleaving is permitted. This is the intent.

-- 
Best regards,
Andrey Tarasevich

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

#83433

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2022-04-03 14:23 +0100
Message-ID	<87sfque1w8.fsf@bsb.me.uk>
In reply to	#83426

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 4/2/2022 1:17 PM, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> 
>>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>>
>>>>>       int r = foo(++i, ++i);
>>>>
>>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>>>>> sequencing to argument evaluation, albeit indeterminate, is a major
>>>>> and a very important change in C++17. How come it is still not
>>>>> implemented in GCC? What are they waiting for? Is there some sort of
>>>>> intentional opposition to that change in the standard?
>>>>
>>>> I'm not an expert on the standard, but according to this page:
>>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>>
>>>> it is not specified. They have exactly your example down the page:
>>>>
>>>> f(++i, ++i);
>>>> // undefined behavior until C++17, unspecified after C++17
>>>>
>>>> To me that sounds like before C+17, the program could segfault, whereas
>>>> with C++17, it can either output 5 or 6, but shold consistently do so.
>>>>
>>>> Am I wrong?
>>>>
>>>>      Christian
>>>
>>> The "unspecified" aspect refers to the ordering of evaluation of the
>>> parameters - they are "indeterminately ordered".
>>>
>>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be either:
>>>
>>> 	a = ++i;
>>> 	b = ++i;
>>> 	foo(a, b);
>>>
>>> or
>>>
>>> 	b = ++i;
>>> 	a = ++i;
>>> 	foo(a, b);
>>>
>>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>>> respectively.  But their sum will be the same.
>>>
>>> It seems gcc has handled this as:
>>>
>>> 	++i;
>>> 	++i;
>>> 	a = i;
>>> 	b = i;
>>>
>>> and AFAIUI, this interleaving is not allowed in C++17.
>> I am not 100% sure.  The wording (C++20 but similar in C++17) is this:
>>    "The initialization of a parameter, including every associated value
>>    computation and side effect, is indeterminately sequenced with respect
>>    to that of any other parameter."
>> That sounds like the two ++i expressions need not to be thought of as
>> units with one sequenced before the other.  It sounds as if any
>> interleaving of the parts is permitted.  At least that's how I would
>> read it, unfamiliar as I am with the way the C++ authors use language.
>
> No, "sequenced before" is a very strong requirement preventing any
> kind of interleaving.

I get that.  My misreading was on what was sequenced before what.  If
the only requirement is that all the value computations, side-effects
and initialisations are indeterminately sequenced with respect to each
other, then gcc's interpretation would be valid.  But if, as is clearly
the intended meaning, all those that pertain to one parameter are (as a
group) indeterminately sequenced with respect to those pertaining to the
other parameters, then the result must f(2, 3) or f(3, 2).

> The quote you provided completely compartmentalizes and isolates
> argument expression evaluation and parameter initialization. No
> interleaving is permitted. This is the intent.

Yes.  I was led astray by the fact that it mentions the value
computations and side effects at all, as if they might be considered
separately. I'd have thought that just talking about indeterminately
sequenced argument evaluation would be clearer.

-- 
Ben.

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

#83499

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Date	2022-04-06 08:31 -0700
Message-ID	<86mtgy9qj5.fsf@linuxsc.com>
In reply to	#83426

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 4/2/2022 1:17 PM, Ben Bacarisse wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 02/04/2022 12:30, Christian Gollwitzer wrote:
>>>
>>>> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
>>>>
>>>>>   int r = foo(++i, ++i);
>>>>>
>>>>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later.  WTF?
>>>>> Adding sequencing to argument evaluation, albeit indeterminate,
>>>>> is a major and a very important change in C++17.  How come it is
>>>>> still not implemented in GCC?  What are they waiting for?  Is
>>>>> there some sort of intentional opposition to that change in the
>>>>> standard?
>>>>
>>>> I'm not an expert on the standard, but according to this page:
>>>> https://en.cppreference.com/w/cpp/language/eval_order
>>>>
>>>> it is not specified.  They have exactly your example down the
>>>> page:
>>>>
>>>> f(++i, ++i);
>>>> // undefined behavior until C++17, unspecified after C++17
>>>>
>>>> To me that sounds like before C+17, the program could segfault,
>>>> whereas with C++17, it can either output 5 or 6, but shold
>>>> consistently do so.
>>>>
>>>> Am I wrong?
>>>
>>> The "unspecified" aspect refers to the ordering of evaluation of
>>> the parameters - they are "indeterminately ordered".
>>>
>>> So given "int foo(int a, int b)", the call "f(++i, ++i)" should be
>>> either:
>>>
>>> 	a = ++i;
>>> 	b = ++i;
>>> 	foo(a, b);
>>>
>>> or
>>>
>>> 	b = ++i;
>>> 	a = ++i;
>>> 	foo(a, b);
>>>
>>> It is thus unspecified whether a and b are 2 and 3, or 3 and 2
>>> respectively.  But their sum will be the same.
>>>
>>> It seems gcc has handled this as:
>>>
>>> 	++i;
>>> 	++i;
>>> 	a = i;
>>> 	b = i;
>>>
>>> and AFAIUI, this interleaving is not allowed in C++17.
>>
>> I am not 100% sure.  The wording (C++20 but similar in C++17) is
>> this:
>>
>>    "The initialization of a parameter, including every associated
>>    value computation and side effect, is indeterminately sequenced
>>    with respect to that of any other parameter."
>>
>> That sounds like the two ++i expressions need not to be thought of
>> as units with one sequenced before the other.  It sounds as if any
>> interleaving of the parts is permitted.  At least that's how I
>> would read it, unfamiliar as I am with the way the C++ authors use
>> language.
>
> No, "sequenced before" is a very strong requirement preventing any
> kind of interleaving.
>
> The modern C++ sequencing terminology abandoned the idea of a
> "sequence point" and switched to some more finely attributed
> variants, which might refer to value computation and side-effects
> separately.  One can say "value computation of the operand is
> sequenced before..." or "side-effects of the argument are
> sequenced after..."
>
> But a plain unattributed "sequenced before (or after)" is
> basically the old-fashioned "sequence point":  a full sequencing
> requirement that covers everything, i.e. the value computation and
> all side-effects together.
>
> The quote you provided completely compartmentalizes and isolates
> argument expression evaluation and parameter initialization.  No
> interleaving is permitted.  This is the intent.

Going just by what is stated in the C++ standard, I would say the
question is clearly ambiguous.

There is no question that the initializations of _parameters_ are
indeterminately sequenced.  But the standard does not say the
evaluations of _argument values_ are indeterminately sequenced.

The standard does use the phrase "every associated value computation
and side effect", but AFAICT there is no definition for what that
phrase means.  Perhaps it is meant to include the evaluation of
argument values, and perhaps it isn't.  What is clear is that the
C++ standard doesn't state which of those possibilities is the case.
Hence, going by just what is stated in the C++ standard, it appears
the question is clearly ambiguous.

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

#83504

From	Andrey Tarasevich <andreytarasevich@hotmail.com>
Date	2022-04-06 11:05 -0700
Message-ID	<t2kkq4$r6c$1@dont-email.me>
In reply to	#83499

On 4/6/2022 8:31 AM, Tim Rentsch wrote:
> 
> Going just by what is stated in the C++ standard, I would say the
> question is clearly ambiguous.
> 
> There is no question that the initializations of _parameters_ are
> indeterminately sequenced.  But the standard does not say the
> evaluations of _argument values_ are indeterminately sequenced.
> 
> The standard does use the phrase "every associated value computation
> and side effect", but AFAICT there is no definition for what that
> phrase means.  Perhaps it is meant to include the evaluation of
> argument values, and perhaps it isn't.  What is clear is that the
> C++ standard doesn't state which of those possibilities is the case.
> Hence, going by just what is stated in the C++ standard, it appears
> the question is clearly ambiguous.

Taken to the extreme, by following this path we'll eventually reach Bill 
Clinton's "It depends on what the meaning of the word 'is' is"...

The language standard does not aim to be that 
semantically/linguistically exhaustive. It is implied that if you 
consider some part of the standard text to be unclear or ambiguous, you 
are supposed to consult the rationale or the corresponding accepted 
proposal for clarification.

In other words, the committee believes that the wording "every 
associated value computation and side effect" contains no ambiguity and 
sufficiently clearly conveys the intent: the argument expression 
evaluations are also indeterminately sequenced.

-- 
Best regards,
Andrey Tarasevich

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

#83712

From	Tim Rentsch <tr.17687@z991.linuxsc.com>
Date	2022-04-25 03:32 -0700
Message-ID	<86o80p8nc5.fsf@linuxsc.com>
In reply to	#83504

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:

> On 4/6/2022 8:31 AM, Tim Rentsch wrote:
>
>> Going just by what is stated in the C++ standard, I would say the
>> question is clearly ambiguous.
>>
>> There is no question that the initializations of _parameters_ are
>> indeterminately sequenced.  But the standard does not say the
>> evaluations of _argument values_ are indeterminately sequenced.
>>
>> The standard does use the phrase "every associated value computation
>> and side effect", but AFAICT there is no definition for what that
>> phrase means.  Perhaps it is meant to include the evaluation of
>> argument values, and perhaps it isn't.  What is clear is that the
>> C++ standard doesn't state which of those possibilities is the case.
>> Hence, going by just what is stated in the C++ standard, it appears
>> the question is clearly ambiguous.
>
> Taken to the extreme, by following this path we'll eventually reach
> Bill Clinton's "It depends on what the meaning of the word 'is' is"...
>
> The language standard does not aim to be that
> semantically/linguistically exhaustive.  It is implied that if you
> consider some part of the standard text to be unclear or ambiguous,
> you are supposed to consult the rationale or the corresponding
> accepted proposal for clarification.

I find this assertion ridiculous.  ISO produces standards documents
that are meant to stand on their own, and where they do need to rely
on other materials they give normative references to the other
documents.  If the people writing the C++ standard expect people to
read the background proposals to make sense of what they write then
they aren't doing their job.  It seems more likely that the writing
was simply careless or the editing was sloppy (or both), which would
be consistent with generally poor writing seen elsewhere in the C++
standard.

> In other words, the committee believes that the wording "every
> associated value computation and side effect" contains no ambiguity
> and sufficiently clearly conveys the intent:  the argument expression
> evaluations are also indeterminately sequenced.

My comment isn't about what the committee believes, only about
what text is present in the C++ standard.  I have no reason to
think you have any special insight into what the committee
believes, especially since no evidence is offered in support
of these fantastic claims.

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

#83420

From	Andrey Tarasevich <andreytarasevich@hotmail.com>
Date	2022-04-02 11:18 -0700
Message-ID	<t2a40u$nl4$1@dont-email.me>
In reply to	#83409

On 4/2/2022 3:30 AM, Christian Gollwitzer wrote:
> Am 02.04.22 um 05:34 schrieb Andrey Tarasevich:
> 
>>      int r = foo(++i, ++i);
> 
>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding 
>> sequencing to argument evaluation, albeit indeterminate, is a major 
>> and a very important change in C++17. How come it is still not 
>> implemented in GCC? What are they waiting for? Is there some sort of 
>> intentional opposition to that change in the standard?
> 
> I'm not an expert on the standard, but according to this page:
> https://en.cppreference.com/w/cpp/language/eval_order
> 
> it is not specified. They have exactly your example down the page:
> 
> f(++i, ++i);
> // undefined behavior until C++17, unspecified after C++17
> 
> To me that sounds like before C+17, the program could segfault, whereas 
> with C++17, it can either output 5 or 6, but shold consistently do so.
> 
> Am I wrong?

You are wrong.

"Unspecified" means that actual behavior is restricted to a well-defined 
set of allowable behaviors. Which behaviors belong to that set depends 
on the specific code.

In this case "unspecified" means that the compiler is allowed to 
evaluate the arguments in unspecified order. However, the evaluation of 
arguments must be sequenced: evaluation of each argument must be 
compartmentalized, i.e. "isolated" from evaluation of other arguments.

Long story short, in this case this boils down to calling either `foo(2, 
3)` or `foo(3, 2)`. Which one will be chosen is what's unspecified. 
That's the only freedom allowed by unspecified behavior in this example.

However, regardless of which variant is chosen, the returned value shall 
still be 5. I deliberately chose the integer `+` operation because its 
result does not depend on the ordering of its operands.

-- 
Best regards,
Andrey Tarasevich

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

#83410

From	David Brown <david.brown@hesbynett.no>
Date	2022-04-02 13:11 +0200
Message-ID	<t29b0g$tsa$1@dont-email.me>
In reply to	#83406

On 02/04/2022 05:34, Andrey Tarasevich wrote:
>   #include <iostream>
> 
>   int foo(int a, int b)
>   {
>     return a + b;
>   }
> 
>   int main()
>   {
>     int i = 1;
>     int r = foo(++i, ++i);
>     std::cout << r << std::endl;
>   }
> 
> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
> sequencing to argument evaluation, albeit indeterminate, is a major and
> a very important change in C++17. How come it is still not implemented
> in GCC? What are they waiting for? Is there some sort of intentional
> opposition to that change in the standard?
> 
> Clang produces the correct 5, but warns about "unsequenced evaluation".
> The warning is nonsensical, but at least they got the result right. This
> - a nonsensical warning accompanied by a correct result - is usually the
> case for all new C++ sequencing rules in Clang.
> 
> MSVC++ quietly produces the correct 5.
> 

This looks like bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78734>

As far as I can tell from the standards, it /is/ a bug in C++17 - the
order of evaluation of the function parameters is indeterminate, which
means you don't know the order but you know that one is completed
(including the initialisation of the parameter) before moving on to the
next.

You might like to add a comment to that bug report - it looks like this
one has been forgotten about.

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

#83418

From	Manu Raju <MR@invalid.invalid>
Date	2022-04-02 18:26 +0100
Message-ID	<t2a15t$vj$1@dont-email.me>
In reply to	#83406

On 02/04/2022 04:34, Andrey Tarasevich wrote:
> #include <iostream>
>
>   int foo(int a, int b)
>   {
>     return a + b;
>   }
>
>   int main()
>   {
>     int i = 1;
>     int r = foo(++i, ++i);
>     std::cout << r << std::endl;
>   }
>
> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding 
> sequencing to argument evaluation, albeit indeterminate, is a major 
> and a very important change in C++17. How come it is still not 
> implemented in GCC? What are they waiting for? Is there some sort of 
> intentional opposition to that change in the standard?
>
> Clang produces the correct 5, but warns about "unsequenced 
> evaluation". The warning is nonsensical, but at least they got the 
> result right. This - a nonsensical warning accompanied by a correct 
> result - is usually the case for all new C++ sequencing rules in Clang.
>
> MSVC++ quietly produces the correct 5.
>
It seems that the evaluation of i takes place before summation according 
to this program:

<===============================================================================>

#include <iostream>

int foo(int a, int b)
{
   return a + b;
}

int main(void)
{
   int i = 1;
   int r = foo(++i, ++i);
   std::cout << i << " + " << i << " = " << r << std::endl; \\ returns 3 
+ 3 = 6;

   return 0;
}

<===============================================================================>

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

#83423

From	Manu Raju <MR@invalid.invalid>
Date	2022-04-02 21:46 +0100
Message-ID	<t2act7$ade$1@dont-email.me>
In reply to	#83406

On 02/04/2022 04:34, Andrey Tarasevich wrote:
>
>
> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding 
> sequencing to argument evaluation, albeit indeterminate, is a major 
> and a very important change in C++17. How come it is still not 
> implemented in GCC? What are they waiting for? Is there some sort of 
> intentional opposition to that change in the standard?
>
>
>
On a further thought about this, ++i means {  i = i + 1} so all is 
(eyes!) becomes a new value. In the example, i becomes 3 because it is 
incremented twice so the correct answer is 6.  If you use i and j as the 
two parameters then you get 4 because both are incremented by 1 
independently.

int i = 1, j = 1;
int r = foo(++i, ++j);

If you have i++ then the value assigned remains the same before 
increasing it.  IOW you get something like: 3 + 3 = 2 because the value 
assigned to i first time is still 1 and this goes to the function to 
make the result 2 but the value of i has moved to 3. This the problem 
with using the same variables!

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

#83427

From	Andrey Tarasevich <andreytarasevich@hotmail.com>
Date	2022-04-02 17:35 -0700
Message-ID	<t2aq56$1td$2@dont-email.me>
In reply to	#83423

On 4/2/2022 1:46 PM, Manu Raju wrote:
> On 02/04/2022 04:34, Andrey Tarasevich wrote:
>>
>>
>> This outputs 6 in GCC 11.2 in `-std=c++17` mode and later. WTF? Adding
>> sequencing to argument evaluation, albeit indeterminate, is a major
>> and a very important change in C++17. How come it is still not
>> implemented in GCC? What are they waiting for? Is there some sort of
>> intentional opposition to that change in the standard?
>>
>>
>>
> On a further thought about this, ++i means {  i = i + 1} so all is
> (eyes!) becomes a new value. In the example, i becomes 3 because it is
> incremented twice so the correct answer is 6.  

Um... You need to read the rest of the discussion instead of making up 
naive theories. It is all explained in great detail in this thread. 
Please make sure you fully understand the issue before offering 
explanations.

The correct answer is 5, not 6.

-- 
Best regards,
Andrey Tarasevich

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

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

csiph-web

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

Contents

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

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

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

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

#83419

#83431

#83435

#83422

#83424

#83425

#83426

#83433

#83499

#83504

#83712

#83420

#83410

#83418

#83423

#83427