Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: GCC hasn't even gotten around to sequencing argument evaluation Date: Tue, 05 Apr 2022 11:31:58 -0700 Organization: None to speak of Lines: 63 Message-ID: <87y20jnzz5.fsf@nosuchdomain.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="bfae2706b1fe0633c749ec48eb22f06e"; logging-data="3223"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18YP8B2oRWPZJLJt4KLtD8q" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:mL/eNyZVTjPcI0B8l2WP4uy9c78= sha1:CfvHC5d+sskb4ajsXjst76PmGm0= Xref: csiph.com comp.lang.c++:83489 Muttley@dastardlyhq.com writes: > On Tue, 5 Apr 2022 08:38:16 -0700 > Andrey Tarasevich wrote: >>On 4/5/2022 8:23 AM, Muttley@dastardlyhq.com wrote: >>> On Mon, 4 Apr 2022 18:34:35 +0200 >>> David Brown wrote: >>>> On 04/04/2022 16:43, Muttley@dastardlyhq.com wrote: >>>>> On Mon, 4 Apr 2022 12:15:42 +0200 >>>>> David Brown 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 */