Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.arch Subject: Re: Optimization by programmers Date: Fri, 02 Oct 2026 22:04:43 -0700 Organization: A noiseless patient Spider Lines: 77 Message-ID: <867bjznzmc.fsf@linuxsc.com> References: <1177fdi$26ea4$1@dont-email.me> <2026Sep13.162747@mips.complang.tuwien.ac.at> <118h4cj$fi2a$1@dont-email.me> <2026Sep19.082513@mips.complang.tuwien.ac.at> <2026Sep21.191719@mips.complang.tuwien.ac.at> <118tshf$r2kv$1@dont-email.me> <118uv1g$18lk0$1@dont-email.me> <119035d$1il2u$1@dont-email.me> <1190p7d$1sdou$1@dont-email.me> <1190ufg$1u1p8$1@dont-email.me> <119159b$21919$1@dont-email.me> <119nar5$2rqdj$1@paganini.bofh.team> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Sat, 03 Oct 2026 05:04:44 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2834329"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19q9xygwxkptIu3UufG/7EUhTn4ainhDPA="; posting-host="b0e28b4afc9fd8b2450f610d134fbfb4" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7uPf6+mfdWIQwn6qBJngbrCIqSc= sha1:14NOXSnd00TnQcMTsAEPo5jjoxY= sha256:iPkAJ9hDFP0nKmjLSBmdaOID26pqfHmGp1MZmR+yzZc= sha1:ilCGb4rh90+yUvtNIHocoww5s34= sha256:ZYInGJmEc3cFBGHxS8nknXAAuGOWIDIGhY70UogVJCA= Xref: csiph.com comp.arch:118415 antispam@fricas.org (Waldek Hebisch) writes: > Stephen Fuld wrote: > >> It is obvious that you are right; the the existing choices as >> documented in the standard and your post above (thanks for that) >> don't permit what I want. I apologize for not recognizing that up >> front. But I maintain that there should be a category that >> essentially says "You can do what you want, but you must document >> what you did." Furthermore, if such a choice existed, most >> instances of undefined should be "reclassified" into that new >> choice. I think that would aid programmers understanding. > > In case of gcc 'ureachable()' can be given simple definition: > optimizer will assume that 'ureachable()' will never be > executed and do program transformations based on that knowledge. > > Consder the following program fragment: > > void foo1(int i) { > if (i < 0) { > unreachable(); > } > foo2(i); > } > > void foo2(int i) { > if (i < 0) { > foo3(i); > } else { > foo4(i); > } > } > > In foo1 compiler could infer that 'i >= 0'. It could also inline > 'foo2' into 'foo1'. After inlining it could infer that 'foo4' > will be called. So compiler could transform 'foo1' into > > void foo1(int i) { > foo4(i); > } > > If ever 'foo1' gets called with negative argument you would get > call to 'foo4' with negative argument. > > Some people have mental model that C is compiled on statement by > statement basis. In compiler that is doing simple statement by > statement compilation 'if' in 'foo2' would prevent call to > 'foo4' with negative argument. If compiler simply replaced > 'unreachable()' by a trap instruction, then program would > trap in ;foo1'. But undefined behaviour opens essentially > unlimied possibilites for program transformation, based on > surrouding code. > > BTW: I can image code using a macro > > #define ASSERT_FACT(x) {if (x) unreachable();} > > and codebase sprinkled with statements like: > > ASSERT_FACT(i >= 0 && i < 100) > > So 'unreachable()' essentially allows passing arbitrary assertions > to the compiler. > > Let me add that given enough facts compiler should be able to > prove that all of them are true. It would be nice to have an > option so that compiler warns if it can not prove that some > 'unreachable()' is really unreachable. > > And note that false statement implies everthing, so if your > 'unreachable()' is wrong then there are unlimited possibilities > for unexpected behaviour. How is this reasoning affected by the change in definition of undefined behavior in C23 (as compared for example with the definitions in C11 or C99)?