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

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

On Tuesday, 5 April 2022 at 16:37:43 UTC+1, Andrey Tarasevich wrote:
> 
> Your expression `a + b * c` has no observable behavior (assuming the 
> identifiers do not represent volatile variables), which means that the 
> compiler is free to do absolutely anything with it as long as the 
> outcome (the observable behavior on the other end of the program) looks 
> correct to an external observer. 
>
The operators might be overloaded to have observable behaviour.

Generally this is bad practice, but one use case is exploratory programming
to demonstrate precedence / order of evaluation rules.
 

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

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

On 4/5/2022 8:55 AM, Malcolm McLean wrote:
> On Tuesday, 5 April 2022 at 16:37:43 UTC+1, Andrey Tarasevich wrote:
>>
>> Your expression `a + b * c` has no observable behavior (assuming the
>> identifiers do not represent volatile variables), which means that the
>> compiler is free to do absolutely anything with it as long as the
>> outcome (the observable behavior on the other end of the program) looks
>> correct to an external observer.
>>
> The operators might be overloaded to have observable behaviour.

... which will immediately detach that behavior from the topic we are 
discussing. Overloaded operators and built-in operators in C++ are two 
completely different worlds with completely different semantics.

> Generally this is bad practice, but one use case is exploratory programming
> to demonstrate precedence / order of evaluation rules.

... not in any way, shape or form applicable to built-in operators.

-- 
Best regards,
Andrey Tarasevich

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

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

On 4/5/22 11:18, 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?
> 

In order to explain sequencing, it's generally best to replace more
complicated expressions into and equivalent set of smaller
expression-statements, with unnamed temporaries in the expression
replaced by named temporaries in the expression statements:

temp1 = a;	// A
temp2 = b; 	// B
temp3 = c;	// C
temp4 = temp2*temp3;	// D
temp5 = temp1 + temp4;	// E

There are two relevant clauses in the standard, both from 6.9.1p10:

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator."

Because of that clause, statements B and C must be evaluated before
statement D, statements C and D must be evaluated before statement E.

That's what you're talking about.

"Except where noted, evaluations of operands of individual operators and
of subexpressions of individual expressions are unsequenced."

Because of that clause, there are no other constraints on the order in
which those statements are evaluated. The following are all legal orders
of evaluation:

ABCDE
ACBDE
BACDE
BCADE
CABDE
CBADE
BCDAE
CBDAE

Now, the order in which statements A, B, and C occur does not matter in
this case. However, if we replaced a, b, and c with expressions that had
side effects (such as a(), b() and c()), the order in which those side
effects happened could matter, and all of the above orders are permitted.
That's what we're talking about.

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

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

On 4/4/22 10:42, 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

You might feel that the two different ++i sub-expressions should be
sequenced, but the standard quite explicitly disagrees:

"Except where noted, evaluations of operands of individual operators and
of subexpressions of individual expressions are unsequenced."
(6.9.1p10). "Except where noted" refers to several different locations
in section 7 of the standard, none of which apply to this code.

The meaning of C++ expressions is not defined in terms of precedence,
but in terms of grammar rules, but many of its grammar rules have the
same effect as precedence. But those grammar rule do not directly
constrain the order of evaluation of sub-expressions. The closest the
standard comes to doing so occurs a few sentences later in the same
paragraph:

"The value computations of the operands of an operator are sequenced
before the value computation of the result of the operator."

Because ++ has higher precedence than binary +, which in turn has higher
precedence than an assignment operator, this means that the value
computations of the first i++ and the value computations of the second
i++ are both sequenced before the value computations of the addition
operator, which in turn is sequenced before the value computations of
the assignment operator. It does NOT mean, however, that the value
computations of the two i++'s are sequenced relative to each other.

> ... - and then do 
> the addition. So if i = 1 at the start then at the end it should be 2 + 3. 
> Taking the value of 'i' at the start and using that for both ++ would be an 
> absurd thing to do. eg:

Nonetheless, that absurd this is explicitly allowed. The very next
sentence of that same paragraph goes on to say:

"If a side effect on a memory location (6.7.1) is unsequenced relative
to either another side effect on the same memory location or a value
computation using the value of any object in the same memory location,
and they are not potentially concurrent (6.9.2), the behavior is undefined."

The next paragraph covers the case where they are potentially concurrent
- being potentially concurrent isn't an escape clause, it just requires
more complicated wording.

This idea originated in the very earliest version of the C standard,
though it was expressed in a much more confusing fashion prior to C11,
which introduced the terms "sequenced", "unsequenced" and
"indeterminately sequenced". Those terms made it a lot easier to express
clearly.
Both the C standard and the C++ standard declare such code undefined
explicitly because the C and C++ committees both felt that writing such
code was a bad idea, and should therefore be discouraged.

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

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

On Mon, 4 Apr 2022 12:27:41 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>the assignment operator. It does NOT mean, however, that the value
>computations of the two i++'s are sequenced relative to each other.

int i = 0;
0 && ++i;
printf("%d\n",i);

You think it might print 1?

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

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

On 4/5/2022 8:21 AM, Muttley@dastardlyhq.com wrote:
> On Mon, 4 Apr 2022 12:27:41 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> the assignment operator. It does NOT mean, however, that the value
>> computations of the two i++'s are sequenced relative to each other.
> 
> int i = 0;
> 0 && ++i;
> printf("%d\n",i);
> 
> You think it might print 1?
> 

How is this relevant?

Binary `&&` has extremely strong and strict sequencing guarantees. 
Binary `+` does not. `&&` and `+` are extremely different in this regard.

Why are you bringing binary `&&` into the picture, when the original 
discussion is about binary `+`? How is it relevant?

-- 
Best regards,
Andrey Tarasevich

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

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

On Tue, 5 Apr 2022 08:41:16 -0700
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>On 4/5/2022 8:21 AM, Muttley@dastardlyhq.com wrote:
>> On Mon, 4 Apr 2022 12:27:41 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> the assignment operator. It does NOT mean, however, that the value
>>> computations of the two i++'s are sequenced relative to each other.
>> 
>> int i = 0;
>> 0 && ++i;
>> printf("%d\n",i);
>> 
>> You think it might print 1?
>> 
>
>How is this relevant?
>
>Binary `&&` has extremely strong and strict sequencing guarantees. 

Ah ok, so suddenly we do have sequencing in some expressions. Glad we cleared
that up.

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

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

On 4/5/2022 8:50 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 5 Apr 2022 08:41:16 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/5/2022 8:21 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 12:27:41 -0400
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> the assignment operator. It does NOT mean, however, that the value
>>>> computations of the two i++'s are sequenced relative to each other.
>>>
>>> int i = 0;
>>> 0 && ++i;
>>> printf("%d\n",i);
>>>
>>> You think it might print 1?
>>>
>>
>> How is this relevant?
>>
>> Binary `&&` has extremely strong and strict sequencing guarantees.
> 
> Ah ok, so suddenly we do have sequencing in some expressions. Glad we cleared
> that up.

"Suddenly"? Is this trolling of some sort?

We've always had strong sequencing guarantees for `&&`, `||`, `?:` and 
`,`. This is so ancient, it comes from the first C standard (if not from 
K&R). Nothing sensational about it. Nothing "sudden" about it.

But this is not what we are talking about here.

-- 
Best regards,
Andrey Tarasevich

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

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

On 4/5/22 11:50, Muttley@dastardlyhq.com wrote:
> On Tue, 5 Apr 2022 08:41:16 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/5/2022 8:21 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 12:27:41 -0400
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> the assignment operator. It does NOT mean, however, that the value
>>>> computations of the two i++'s are sequenced relative to each other.
>>>
>>> int i = 0;
>>> 0 && ++i;
>>> printf("%d\n",i);
>>>
>>> You think it might print 1?
>>>
>>
>> How is this relevant?
>>
>> Binary `&&` has extremely strong and strict sequencing guarantees. 
>
> Ah ok, so suddenly we do have sequencing in some expressions. Glad we
> cleared
> that up.

You were unaware of that? Sorry, I didn't know. Yes, a few types of
expressions do have sequence requirements beyond the basic requirement
that value computations of sub-expressions are sequenced before value
computations of the expression itself. Most do not. Postfix ++, binary
+, and simple assignment are the relevant expression types for i = i++ +
i++, and none of them impose sufficient sequence requirements to avoid
this problem.

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

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

On 4/5/22 11:21, Muttley@dastardlyhq.com wrote:
> On Mon, 4 Apr 2022 12:27:41 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> the assignment operator. It does NOT mean, however, that the value
>> computations of the two i++'s are sequenced relative to each other.
>
> int i = 0;
> 0 && ++i;
> printf("%d\n",i);
>
> You think it might print 1?

Of course it won't. Why do you think that example is relevant? There's
two problems with 0 && ++i as a counter-example

7.6.14p2 says "the second operand is not evaluated if the first operand
is false.".

The relevant clause says:
"If a side effect on a memory location (6.7.1) is unsequenced relative
to either another side effect on the same memory location or a value
computation using the value of any object in the same memory location,
and they are not potentially concurrent (6.9.2), the behavior is undefined."

0 && i++ doesn't have any side effects, and does not contain a
computation using the value of any object. Since it has neither of those
things, they can't be unsequenced relative to each other.

That issue does come up in the case of `i = i++ + i++`. To make that
clear, let me break it up into an equivalent set of short
statement-expressions:

temp1 = i; // A
temp2 = i; // B
temp3 = temp1 + 1; // C
temp4 = temp2 + 1; // D
i = temp3; // E
i = temp4; // F
temp5 = temp1 + temp2; //G
i = temp5; // H

The first i++ imposes the requirement that A must be sequenced before C
or G, and that C must be sequenced before E.
The second i++ imposes the requirement that B must be sequenced before D
or G, and that D must be sequenced before F.
The addition imposes the requirement that A and B must both be sequenced
before G.
The assignment imposes the requirement that G must be sequenced before H.

However, 6.9.1p10 also says that "Except where noted, evaluations of
operands of individual operators and of subexpressions of individual
expressions are unsequenced." Therefore, there are no other constraints
on the sequence in which those statements must be executed. There's a
couple of dozen dozen different orders of evaluation that are consistent
with those requirements, before realizing that it would be simpler just
to concentrate on the individual statements whose lack of relative
sequencing is problematic.

The value computations that use the value of i are A and B.
The side effects on i are E, F, H.

Statement A can occur either before or after F. Two of the many
permitted orders of evaluation are:
ABCDEFGH
BDFACEGH


Statement B can happen either before or E. Two of the many permitted
orders of evaluation are:
BADCFEGH
ACEBDFGH


Either of those facts would be sufficient, because of 6.9.1p10, to
render the behavior undefined.

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

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

On 04/04/2022 16:42, 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. 
> Taking the value of 'i' at the start and using that for both ++ would be an 
> absurd thing to do. eg:
> 
> If I did
> 
> i = random() + random() 
> 
> I wouldn't expect the compiler to just call random() once and use that value
> on both sides of the expression.
> 

C and C++ /could/ be defined to handle things the way you suggest - but
they are not.

Precedence rules are not the same as evaluation order.


(Leaving some things undefined or unspecified can make it easier to have
code that is portable to significantly different platforms, it can
improve optimisation, and it can stop people thinking silly things make
sense just because the language says the result is "defined".)

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

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

On 4/2/2022 8:39 AM, Muttley@dastardlyhq.com wrote:
> On Sat, 2 Apr 2022 17:27:39 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 02/04/2022 16:28, Muttley@dastardlyhq.com wrote:
>>> 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 C++17, the incrementing is indeterminate order.  Prior to that, it is
>> undefined behaviour.  UB /could/ do anything.  If the compiler happens
> 
> Undefined simply means no one cared enough to define it. The compiler writers
> would have to deliberately change their parameter parsing and stack pushing
> code in order to crash in this instance.
> 

Oh yes, they would!

Try this in GCC

    int &foo()
    {
      int a = 42;
      return a;   // Undefined behavior
    }

    int main()
    {
      std::cout << foo() << std::endl;
    }

This is a different example of undefined behavior. This code will 
segfault in GCC because the compiler writers decided to _deliberately_ 
return "null reference" from the above function. They didn't have to. 
Yet they did so on purpose: to deliberately punish those who have a 
habit of gratuitously returning references/pointers to local variables.

On top of that, undefined behavior is first and foremost an optimization 
opportunity. An equivalent definition of undefined behavior says: the 
compilers are allowed to translate the code under assumption that 
undefined behavior never happens.

The code transformations that modern optimizers perform under the above 
assumption are extremely far-reaching and sometimes just shockingly 
dumbfounding. It is true: anything can happen. Even the proverbial 
formatting of your hard drive.

https://kristerw.blogspot.com/2017/09/why-undefined-behavior-may-call-never.html

-- 
Best regards,
Andrey Tarasevich

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

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

On Sat, 2 Apr 2022 11:27:59 -0700
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>On 4/2/2022 8:39 AM, Muttley@dastardlyhq.com wrote:
>> Undefined simply means no one cared enough to define it. The compiler writers
>
>> would have to deliberately change their parameter parsing and stack pushing
>> code in order to crash in this instance.
>> 
>
>Oh yes, they would!
>
>Try this in GCC
>
>    int &foo()
>    {
>      int a = 42;
>      return a;   // Undefined behavior
>    }
>
>    int main()
>    {
>      std::cout << foo() << std::endl;
>    }
>
>This is a different example of undefined behavior. This code will 
>segfault in GCC because the compiler writers decided to _deliberately_ 
>return "null reference" from the above function. They didn't have to. 
>Yet they did so on purpose: to deliberately punish those who have a 
>habit of gratuitously returning references/pointers to local variables.

Seems a good idea to me given otherwise it would be a bug that would probably
remain hidden causing random behaviour until someone spent time tracking it 
down.

>opportunity. An equivalent definition of undefined behavior says: the 
>compilers are allowed to translate the code under assumption that 
>undefined behavior never happens.

Except if it can be written in code then at some point it will happen.

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

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

On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
> On Sat, 2 Apr 2022 11:27:59 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>> On 4/2/2022 8:39 AM, Muttley@dastardlyhq.com wrote:
>>> Undefined simply means no one cared enough to define it. The compiler writers
>>
>>> would have to deliberately change their parameter parsing and stack pushing
>>> code in order to crash in this instance.
>>>
>>
>> Oh yes, they would!
>>
>> Try this in GCC
>>
>>     int &foo()
>>     {
>>       int a = 42;
>>       return a;   // Undefined behavior
>>     }
>>
>>     int main()
>>     {
>>       std::cout << foo() << std::endl;
>>     }
>>
>> This is a different example of undefined behavior. This code will
>> segfault in GCC because the compiler writers decided to _deliberately_
>> return "null reference" from the above function. They didn't have to.
>> Yet they did so on purpose: to deliberately punish those who have a
>> habit of gratuitously returning references/pointers to local variables.

I would suppose the code deliberately returns a null reference to avoid 
a glaring security hole that might be abused.  (I don't expect it could 
be abused in this limited example, but invalid stack references 
certainly have been used for attacks in some cases.)  It's better to 
have a program crash quickly on such bugs than have the risk of hidden 
security flaws.

Note that gcc warns you about the problem - even if you don't enable 
warnings.

Newer versions of gcc will generate the "ud2" instruction (on x86-64) 
when you attempt to read the value of "foo()".  This forces an 
"undefined behaviour" fault.

> 
> Seems a good idea to me given otherwise it would be a bug that would probably
> remain hidden causing random behaviour until someone spent time tracking it
> down.
> 

Yes, at least in this case.

>> opportunity. An equivalent definition of undefined behavior says: the
>> compilers are allowed to translate the code under assumption that
>> undefined behavior never happens.
> 
> Except if it can be written in code then at some point it will happen.
> 

That is not even /remotely/ true.

gcc even has a way "__builtin_unreachable()" to specifically say that 
code flow cannot reach a particular point, and this is handled 
internally in /precisely/ the same way as undefined behaviour.

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

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

On Mon, 4 Apr 2022 12:15:42 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>> On Sat, 2 Apr 2022 11:27:59 -0700
>>> opportunity. An equivalent definition of undefined behavior says: the
>>> compilers are allowed to translate the code under assumption that
>>> undefined behavior never happens.
>> 
>> Except if it can be written in code then at some point it will happen.
>> 
>
>That is not even /remotely/ true.
>
>gcc even has a way "__builtin_unreachable()" to specifically say that 
>code flow cannot reach a particular point, and this is handled 
>internally in /precisely/ the same way as undefined behaviour.

What has unreachable code got to do with anything?

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

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

On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote:
> On Mon, 4 Apr 2022 12:15:42 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>>> On Sat, 2 Apr 2022 11:27:59 -0700
>>>> opportunity. An equivalent definition of undefined behavior says: the
>>>> compilers are allowed to translate the code under assumption that
>>>> undefined behavior never happens.
>>>
>>> Except if it can be written in code then at some point it will happen.
>>>
>>
>> That is not even /remotely/ true.
>>
>> gcc even has a way "__builtin_unreachable()" to specifically say that 
>> code flow cannot reach a particular point, and this is handled 
>> internally in /precisely/ the same way as undefined behaviour.
> 
> What has unreachable code got to do with anything?
> 

As I wrote - gcc treats code marked explicitly as "unreachable" in the
same way as it treats undefined behaviour.  (And I really mean that - it
uses the same node type in the internal tree representation of the
code.)  In other words, when the compiler sees undefined behaviour, it
/knows/ that code flow never enters there.  If your code has the line "i
= i++ + ++i;", the compiler can replace it with
"__builtin_unreachable()" and know it will not be executed.

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

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

On Mon, 4 Apr 2022 18:34:35 +0200
David Brown <david.brown@hesbynett.no> wrote:
>On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote:
>> On Mon, 4 Apr 2022 12:15:42 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>>>> On Sat, 2 Apr 2022 11:27:59 -0700
>>>>> opportunity. An equivalent definition of undefined behavior says: the
>>>>> compilers are allowed to translate the code under assumption that
>>>>> undefined behavior never happens.
>>>>
>>>> Except if it can be written in code then at some point it will happen.
>>>>
>>>
>>> That is not even /remotely/ true.
>>>
>>> gcc even has a way "__builtin_unreachable()" to specifically say that 
>>> code flow cannot reach a particular point, and this is handled 
>>> internally in /precisely/ the same way as undefined behaviour.
>> 
>> What has unreachable code got to do with anything?
>> 
>
>As I wrote - gcc treats code marked explicitly as "unreachable" in the
>same way as it treats undefined behaviour.  (And I really mean that - it
>uses the same node type in the internal tree representation of the
>code.)  In other words, when the compiler sees undefined behaviour, it
>/knows/ that code flow never enters there.  If your code has the line "i
>= i++ + ++i;", the compiler can replace it with
>"__builtin_unreachable()" and know it will not be executed.

Except it clearly is executed as any short test program would demonstrate.

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

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

On 4/5/2022 8:23 AM, Muttley@dastardlyhq.com wrote:
> On Mon, 4 Apr 2022 18:34:35 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>> On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 12:15:42 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>>>>> On Sat, 2 Apr 2022 11:27:59 -0700
>>>>>> opportunity. An equivalent definition of undefined behavior says: the
>>>>>> compilers are allowed to translate the code under assumption that
>>>>>> undefined behavior never happens.
>>>>>
>>>>> Except if it can be written in code then at some point it will happen.
>>>>>
>>>>
>>>> That is not even /remotely/ true.
>>>>
>>>> gcc even has a way "__builtin_unreachable()" to specifically say that
>>>> code flow cannot reach a particular point, and this is handled
>>>> internally in /precisely/ the same way as undefined behaviour.
>>>
>>> What has unreachable code got to do with anything?
>>>
>>
>> As I wrote - gcc treats code marked explicitly as "unreachable" in the
>> same way as it treats undefined behaviour.  (And I really mean that - it
>> uses the same node type in the internal tree representation of the
>> code.)  In other words, when the compiler sees undefined behaviour, it
>> /knows/ that code flow never enters there.  If your code has the line "i
>> = i++ + ++i;", the compiler can replace it with
>> "__builtin_unreachable()" and know it will not be executed.
> 
> Except it clearly is executed as any short test program would demonstrate.
> 

"Test programs" don't demonstrate anything at all.

-- 
Best regards,
Andrey Tarasevich

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

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

On Tue, 5 Apr 2022 08:38:16 -0700
Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>On 4/5/2022 8:23 AM, Muttley@dastardlyhq.com wrote:
>> On Mon, 4 Apr 2022 18:34:35 +0200
>> David Brown <david.brown@hesbynett.no> wrote:
>>> On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote:
>>>> On Mon, 4 Apr 2022 12:15:42 +0200
>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>> On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>>>>>> On Sat, 2 Apr 2022 11:27:59 -0700
>>>>>>> opportunity. An equivalent definition of undefined behavior says: the
>>>>>>> compilers are allowed to translate the code under assumption that
>>>>>>> undefined behavior never happens.
>>>>>>
>>>>>> Except if it can be written in code then at some point it will happen.
>>>>>>
>>>>>
>>>>> That is not even /remotely/ true.
>>>>>
>>>>> gcc even has a way "__builtin_unreachable()" to specifically say that
>>>>> code flow cannot reach a particular point, and this is handled
>>>>> internally in /precisely/ the same way as undefined behaviour.
>>>>
>>>> What has unreachable code got to do with anything?
>>>>
>>>
>>> As I wrote - gcc treats code marked explicitly as "unreachable" in the
>>> same way as it treats undefined behaviour.  (And I really mean that - it
>>> uses the same node type in the internal tree representation of the
>>> code.)  In other words, when the compiler sees undefined behaviour, it
>>> /knows/ that code flow never enters there.  If your code has the line "i
>>> = i++ + ++i;", the compiler can replace it with
>>> "__builtin_unreachable()" and know it will not be executed.
>> 
>> Except it clearly is executed as any short test program would demonstrate.
>> 
>
>"Test programs" don't demonstrate anything at all.

So how would you demonstrate how a compiler treats some code then? Ask it?

int main()
{
	int i = 0;
	i = i++ + ++i;
	printf("%d\n",i);
	return 0;
}

The output with clang is 1, 2 with gcc. If what you said was correct the
result would be 0, an abort or some kind of compilation error.

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

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

Muttley@dastardlyhq.com writes:
> On Tue, 5 Apr 2022 08:38:16 -0700
> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote:
>>On 4/5/2022 8:23 AM, Muttley@dastardlyhq.com wrote:
>>> On Mon, 4 Apr 2022 18:34:35 +0200
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote:
>>>>> On Mon, 4 Apr 2022 12:15:42 +0200
>>>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>>> On 04/04/2022 10:23, Muttley@dastardlyhq.com wrote:
>>>>>>> On Sat, 2 Apr 2022 11:27:59 -0700
>>>>>>>> opportunity. An equivalent definition of undefined behavior says: the
>>>>>>>> compilers are allowed to translate the code under assumption that
>>>>>>>> undefined behavior never happens.
>>>>>>>
>>>>>>> Except if it can be written in code then at some point it will happen.
>>>>>>>
>>>>>>
>>>>>> That is not even /remotely/ true.
>>>>>>
>>>>>> gcc even has a way "__builtin_unreachable()" to specifically say that
>>>>>> code flow cannot reach a particular point, and this is handled
>>>>>> internally in /precisely/ the same way as undefined behaviour.
>>>>>
>>>>> What has unreachable code got to do with anything?
>>>>>
>>>>
>>>> As I wrote - gcc treats code marked explicitly as "unreachable" in the
>>>> same way as it treats undefined behaviour.  (And I really mean that - it
>>>> uses the same node type in the internal tree representation of the
>>>> code.)  In other words, when the compiler sees undefined behaviour, it
>>>> /knows/ that code flow never enters there.  If your code has the line "i
>>>> = i++ + ++i;", the compiler can replace it with
>>>> "__builtin_unreachable()" and know it will not be executed.
>>> 
>>> Except it clearly is executed as any short test program would demonstrate.
>>> 
>>
>>"Test programs" don't demonstrate anything at all.
>
> So how would you demonstrate how a compiler treats some code then? Ask it?
>
> int main()
> {
> 	int i = 0;
> 	i = i++ + ++i;
> 	printf("%d\n",i);
> 	return 0;
> }
>
> The output with clang is 1, 2 with gcc. If what you said was correct the
> result would be 0, an abort or some kind of compilation error.

We're talking about what the standard *allows* compilers to do, whether
any actual compiler takes advantage of that permission or not.

The statement was that a compiler *can* replace `i = i++ + ++i;`
with `__builtin_unreachable()`, not that it *must*.

-- 
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]

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

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

csiph-web