Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #83406 > unrolled thread
| 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 1 of 7 [1] 2 3 4 5 6 7 Next page →
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-04-01 20:34 -0700 |
| Subject | GCC hasn't even gotten around to sequencing argument evaluation yet??? |
| Message-ID | <t28g93$cou$1@dont-email.me> |
#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.
--
Best regards,
Andrey Tarasevich
[toc] | [next] | [standalone]
| From | "Alf P. Steinbach" <alf.p.steinbach@gmail.com> |
|---|---|
| Date | 2022-04-02 10:19 +0200 |
| Message-ID | <t290vc$pm7$1@dont-email.me> |
| In reply to | #83406 |
On 2 Apr 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.
Not sure.
Another issue with g++, at least MinGW g++ version 9.2.0, and unless I
have a learning opportunity here wrt. the C++ language, that
`static_assert` is evaluated in a dead code branch of a `constexpr if`.
template< class T >
auto foo() -> int
{
if constexpr( sizeof( T ) == 1 ) {
return 42;
} else {
static_assert( false, "Ungood template argument, must be a
byte type." );
}
}
auto main() -> int
{
return foo<char>();
}
As I see it a `static_assert` in a dead code branch can even be
malformed, invalid code, e.g. by referring to a variable of
not-the-assumed-type, so it's nonsensical to have it evaluated. Hence I
believe that the standard makes it so and that g++ is Just Wrong(tm) here.
- Alf
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2022-04-02 12:19 +0200 |
| Message-ID | <jaqm9pFh056U1@mid.individual.net> |
| In reply to | #83407 |
On 2022-04-02 at 10:19, Alf P. Steinbach wrote:
> On 2 Apr 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.
>
> Not sure.
>
> Another issue with g++, at least MinGW g++ version 9.2.0, and unless I
> have a learning opportunity here wrt. the C++ language, that
> `static_assert` is evaluated in a dead code branch of a `constexpr if`.
>
> template< class T >
> auto foo() -> int
> {
> if constexpr( sizeof( T ) == 1 ) {
> return 42;
> } else {
> static_assert( false, "Ungood template argument, must be a
> byte type." );
> }
> }
>
> auto main() -> int
> {
> return foo<char>();
> }
>
> As I see it a `static_assert` in a dead code branch can even be
> malformed, invalid code, e.g. by referring to a variable of
> not-the-assumed-type, so it's nonsensical to have it evaluated. Hence I
> believe that the standard makes it so and that g++ is Just Wrong(tm) here.
>
> - Alf
>
>
static_assert(false) is *always* ill-formed, as there is no type T for
which the else-part could compile. The compiler is allowed to diagnose this.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-02 14:18 +0200 |
| Message-ID | <t29etr$8cq$1@dont-email.me> |
| In reply to | #83407 |
Am 02.04.2022 um 10:19 schrieb Alf P. Steinbach:
> On 2 Apr 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.
>
> Not sure.
>
> Another issue with g++, at least MinGW g++ version 9.2.0, and unless I
> have a learning opportunity here wrt. the C++ language, that
> `static_assert` is evaluated in a dead code branch of a `constexpr if`.
>
> template< class T >
> auto foo() -> int
> {
> if constexpr( sizeof( T ) == 1 ) {
> return 42;
> } else {
> static_assert( false, "Ungood template argument, must be a
> byte type." );
> }
> }
template<class T>
requires (sizeof(T) == 1)
int foo()
{
return 42;
}
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2022-04-02 12:30 +0200 |
| Message-ID | <t298jp$duj$1@dont-email.me> |
| In reply to | #83406 |
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
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-04-02 14:12 +0200 |
| Message-ID | <t29ej1$5dk$1@dont-email.me> |
| In reply to | #83409 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2022-04-02 14:20 +0200 |
| Message-ID | <t29f2s$8cq$2@dont-email.me> |
| In reply to | #83411 |
Am 02.04.2022 um 14:12 schrieb David Brown: > 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; Thank you for this explanation.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-02 14:28 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t29mij$1bk8$1@gioia.aioe.org> |
| In reply to | #83411 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-04-02 17:27 +0200 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t29q1c$hf1$1@dont-email.me> |
| In reply to | #83414 |
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 to implement it as though you had written the code I suggested above, it would not segfault. But it could have done other things. (In some cases, gcc replaces clearly undefined behaviour with a trap instruction.) The point is, when code has no defined behaviour (determined either by the C++ standards, additional standards like POSIX, documented compiler features, etc.), then you can't rely on it for any purpose.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-02 15:39 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t29qms$18lf$1@gioia.aioe.org> |
| In reply to | #83415 |
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. >POSIX, documented compiler features, etc.), then you can't rely on it >for any purpose. You can't rely on a rusty bicycle working, but its not going to shoot you in the head.
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@delq.com> |
|---|---|
| Date | 2022-04-02 09:15 -0700 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t1tg4hdokpjqagckllag4839rkn9ssag4a@4ax.com> |
| In reply to | #83416 |
On Sat, 2 Apr 2022 15:39:08 -0000 (UTC), 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.
While that may be true for some examples of undefined behavior, there
are other instances where the behavior is specified as undefined.
Consider
i = ++i + ++i;
There is an clause in the standard that says this type of computation
is undefined.
>>POSIX, documented compiler features, etc.), then you can't rely on it
>>for any purpose.
>
>You can't rely on a rusty bicycle working, but its not going to shoot you in
>the head.
But it might drop you on your head.
The frequent use of exaggeration (there is no credible case of
undefined behavior buying anyone flowers) when describing undefined
behavior is to catch your attention and convince you it is something
to be avoided. There are numerous examples of undefined behavior that
may (should!) result in a segfault or similar termination of your
program, such as accessing beyond the range of allocated memory. IMO,
failure to do so poses an unacceptable security risk.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-04 08:21 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2e9qb$q6l$1@gioia.aioe.org> |
| In reply to | #83417 |
On Sat, 02 Apr 2022 09:15:41 -0700 Barry Schwarz <schwarzb@delq.com> wrote: >On Sat, 2 Apr 2022 15:39:08 -0000 (UTC), 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. > >While that may be true for some examples of undefined behavior, there >are other instances where the behavior is specified as undefined. >Consider > i = ++i + ++i; >There is an clause in the standard that says this type of computation >is undefined. Perhaps it should be defined as it looks reasonable to me. What does the standard say about i = (++i) + (++i) ? >The frequent use of exaggeration (there is no credible case of >undefined behavior buying anyone flowers) when describing undefined I was thinking more of the segfaulting comment for the specific example.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-04-04 12:02 +0200 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2efo4$jqc$1@dont-email.me> |
| In reply to | #83449 |
On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote: > On Sat, 02 Apr 2022 09:15:41 -0700 > Barry Schwarz <schwarzb@delq.com> wrote: >> On Sat, 2 Apr 2022 15:39:08 -0000 (UTC), 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. >> >> While that may be true for some examples of undefined behavior, there >> are other instances where the behavior is specified as undefined. >> Consider >> i = ++i + ++i; >> There is an clause in the standard that says this type of computation >> is undefined. > > 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. >> The frequent use of exaggeration (there is no credible case of >> undefined behavior buying anyone flowers) when describing undefined > > I was thinking more of the segfaulting comment for the specific example. > Segfault is quite unlikely for this particular case, with such an isolated snippet. But you have no guarantees.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-04 14:42 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2f03t$kt$1@gioia.aioe.org> |
| In reply to | #83455 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-04-04 08:49 -0700 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2f420$q7p$1@dont-email.me> |
| In reply to | #83462 |
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. > Taking the value of 'i' at the start and using that for both ++ would be an > absurd thing to do. That's undefined behavior for you. Undefined behavior is allowed to do absurd things. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-05 15:18 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2hmk6$1nno$1@gioia.aioe.org> |
| In reply to | #83464 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Andrey Tarasevich <andreytarasevich@hotmail.com> |
|---|---|
| Date | 2022-04-05 08:37 -0700 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2hnnm$c47$1@dont-email.me> |
| In reply to | #83475 |
On 4/5/2022 8:18 AM, Muttley@dastardlyhq.com wrote: > On Mon, 4 Apr 2022 08:49:18 -0700 > Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >> On 4/4/2022 7:42 AM, Muttley@dastardlyhq.com wrote: >>> On Mon, 4 Apr 2022 12:02:44 +0200 >>> David Brown <david.brown@hesbynett.no> wrote: >>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote: >>>>> Perhaps it should be defined as it looks reasonable to me. What does the >>>>> standard say about i = (++i) + (++i) ? >>>>> >>>> >>>> The same thing - undefined behaviour. Parentheses do not affect the >>>> order of evaluation. >>> >>> I don't understand why it should be undefined. It should evaluate both sides >>> of the argument in order they're defined - and it has to be in order or >>> precedance checks, lazy evaluation and function calls could fail - and then >> do >>> the addition. So if i = 1 at the start then at the end it should be 2 + 3. >> >> That's a lot of "should" and "has to be" with no connection to reality. >> >> C and C++ don't work that way. Precedence in C and C++ has no relation >> to order of evaluation for built-in operators. > > Really? So if I write a + b * c it might evaluate a + b first? You sure > about that? > Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one knows what it will evaluate first and how it will evaluate it. 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. Operator precedence and associativity dictate the standard semantics of `a + b * c` and therefore dictate the correct result of `a + b * c`. But they don't dictate anything about how the compiler is supposed to obtain that result. It might evaluate it as `(a + b) * c - a * (c - 1)` if it so desires, as long as the observable semantics is preserved. Or it might even drop the evaluation entirely. -- Best regards, Andrey Tarasevich
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2022-04-05 15:54 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2hon3$rje$1@gioia.aioe.org> |
| In reply to | #83478 |
On Tue, 5 Apr 2022 08:37:23 -0700 Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >On 4/5/2022 8:18 AM, Muttley@dastardlyhq.com wrote: >> On Mon, 4 Apr 2022 08:49:18 -0700 >> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >>> On 4/4/2022 7:42 AM, Muttley@dastardlyhq.com wrote: >>>> On Mon, 4 Apr 2022 12:02:44 +0200 >>>> David Brown <david.brown@hesbynett.no> wrote: >>>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote: >>>>>> Perhaps it should be defined as it looks reasonable to me. What does the >>>>>> standard say about i = (++i) + (++i) ? >>>>>> >>>>> >>>>> The same thing - undefined behaviour. Parentheses do not affect the >>>>> order of evaluation. >>>> >>>> I don't understand why it should be undefined. It should evaluate both >sides >>>> of the argument in order they're defined - and it has to be in order or >>>> precedance checks, lazy evaluation and function calls could fail - and then > >>> do >>>> the addition. So if i = 1 at the start then at the end it should be 2 + 3. >>> >>> That's a lot of "should" and "has to be" with no connection to reality. >>> >>> C and C++ don't work that way. Precedence in C and C++ has no relation >>> to order of evaluation for built-in operators. >> >> Really? So if I write a + b * c it might evaluate a + b first? You sure >> about that? >> > >Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one >knows what it will evaluate first and how it will evaluate it. And why would it evaluate a+b when the result would be thrown away unless 'c' happened to be 1? Is this some special compiler guaranteed to produce the least efficient binary possible?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-04-06 11:24 +0200 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2jm8n$jhl$1@dont-email.me> |
| In reply to | #83484 |
On 05/04/2022 17:54, Muttley@dastardlyhq.com wrote: > On Tue, 5 Apr 2022 08:37:23 -0700 > Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >> On 4/5/2022 8:18 AM, Muttley@dastardlyhq.com wrote: >>> On Mon, 4 Apr 2022 08:49:18 -0700 >>> Andrey Tarasevich <andreytarasevich@hotmail.com> wrote: >>>> On 4/4/2022 7:42 AM, Muttley@dastardlyhq.com wrote: >>>>> On Mon, 4 Apr 2022 12:02:44 +0200 >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> On 04/04/2022 10:21, Muttley@dastardlyhq.com wrote: >>>>>>> Perhaps it should be defined as it looks reasonable to me. What does the >>>>>>> standard say about i = (++i) + (++i) ? >>>>>>> >>>>>> >>>>>> The same thing - undefined behaviour. Parentheses do not affect the >>>>>> order of evaluation. >>>>> >>>>> I don't understand why it should be undefined. It should evaluate both >> sides >>>>> of the argument in order they're defined - and it has to be in order or >>>>> precedance checks, lazy evaluation and function calls could fail - and then >> >>>> do >>>>> the addition. So if i = 1 at the start then at the end it should be 2 + 3. >>>> >>>> That's a lot of "should" and "has to be" with no connection to reality. >>>> >>>> C and C++ don't work that way. Precedence in C and C++ has no relation >>>> to order of evaluation for built-in operators. >>> >>> Really? So if I write a + b * c it might evaluate a + b first? You sure >>> about that? >>> >> >> Absolutely! In fact, it can evaluate `(a + c / x) * 42` first. No one >> knows what it will evaluate first and how it will evaluate it. > > And why would it evaluate a+b when the result would be thrown away unless > 'c' happened to be 1? Is this some special compiler guaranteed to produce the > least efficient binary possible? > You seem to have missed the point entirely. Andrey is completely correct here. But perhaps the examples chosen have mislead you - while a compiler is free to evaluate things any way it wants (as long as observable behaviour is maintained), compilers don't go out of their way to do things inefficiently. Let's try some slightly more realistic examples, and see if you get the point. Say you write "x = a + (b - c);". Maybe you've chosen parenthesis based on what you know about the values of a, b, and c, and you know this way no sub-expression overflows. Do you think the compiler must do "b - c" first, then add "a" ? If so, you would be wrong. It can evaluate in any order it likes as long as the results have the same behaviour as the language semantics demand. So it can happily do "a + b" and then subtract "c", or "a - c" and then add "b", or negate "c" and then use a three-way add instruction if the cpu has such a thing. Given "a * (b + c)", the compiler might choose to evaluate "a * b", "a * c", then add them together, if it has knowledge of the values that make that more efficient (perhaps such re-ordering would let it use smaller width multiplication instructions). It could also re-order "(a * b) + (a * c)" into "a * (b + c)" if that made more sense. As long as the results are the same for any possible values of the variables for which there are no signed overflows in original expression, any order of evaluation is allowed.
[toc] | [prev] | [next] | [standalone]
| From | Juha Nieminen <nospam@thanks.invalid> |
|---|---|
| Date | 2022-04-06 10:49 +0000 |
| Subject | Re: GCC hasn't even gotten around to sequencing argument evaluation |
| Message-ID | <t2jr7h$r65$1@gioia.aioe.org> |
| In reply to | #83495 |
David Brown <david.brown@hesbynett.no> wrote: > As long as the results are the same for any possible values of the > variables for which there are no signed overflows in original > expression, any order of evaluation is allowed. While not completely relevant to this discussion, this somehow reminded me of the gcc (and clang) option -ffast-math, which gives the compiler express permission to do (floating point) optimizations that are, strictly speaking, not allowed by the standard (because according to the standard optimizations must not affect observable behavior, other than runtime). It can sometimes be a bit surprising what kind of optimizations the compiler is *not* allowed to perform, unless explicitly allowed to bypass the strictest requirements of the language standard. For example, the compiler is not allowed to optimize "x*0.0" into "0.0" because that changes observable behavior if x is inf or NaN. (-ffast-math allows it to do that optimization.) Likewise it cannot optimize "(x+y)-x" into "y" because the result of the expression may not be exactly "y" (because of the limited size of the mantissa, or because "x+y" may result in inf or -inf.) The same is true for many other expressions that could mathematically be reduced but the compiler isn't allowed to do because with floating point the result may not be the same. (Again, -ffast-math gives it permission to do that type of optimization.)
[toc] | [prev] | [next] | [standalone]
Page 1 of 7 [1] 2 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web