On Wed, 17 Sept 2025 at 13:39, Nate Eldredge <nate_at_[hidden]>
wrote:

> On Sep 16, 2025, at 20:11, Yongwei Wu via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>
> I am wondering what are the real-world benefits of the forward progress
> guarantee today.... They probably existed, but are they still there? (If
> not, should we ...?)
>
>
> I thought the canonical example was something like
> https://godbolt.org/z/G6onne47x:
>
> [[gnu::pure]] int update(int) ; // opaque but known to have no side
> effects
>
> void foo(void) {
> int r = 1;
> while (r != 0) {
> r = update(r);
> }
> // no further use of r
> }
>
> Instead of an opaque pure function, you may imagine replacing `update`
> with a sufficiently complicated expression having no side effects, such
> that the compiler cannot reasonably determine if it will return 0 within
> finitely many iterations.
>
> With the "forward progress guarantee" (I assume you refer to
> https://eel.is/c++draft/intro.progress#1) the compiler can and will
> delete the loop as dead code, and optimize `foo()` into just a `ret`.
> Without it (use `-fno-finite-loops`), the compiler must emit code to
> actually execute all iterations of the loop, since if it turns out the loop
> does not terminate, the function `foo()` must never return.
>
> Such examples, where we have complicated code to compute a value that is
> not used, must be very common in auto-generated code, and people rely
> heavily on compilers to optimize it out.
>

I can hardly imagine it is "common". Who would have written such code,
especially when it never terminates? I would argue that an infinite loop is
better, in that it would alert the programmer that something is broken. To
me (and I believe to most C++ programmers), this is a surprising
optimization. I really have difficulty imagining it is truly useful.

There are other examples showing this is a bad optimization, say, the
infamous disproof of Fermat's last theorem:

https://godbolt.org/z/TbYbWzhGq

Yup, it is a bit artificial too, in that a good verification function
should return three states instead of two. But I do not think it is more
artificial than programmers writing useless loops and hoping the compiler
will get rid of it automagically.

By the way, I had colleagues truly bitten by this "optimization", so I did
see real-world damages caused by this "optimization".

Anyway, I honestly want to see real-world benefits of the forward progress
guarantee. Not theoretical ones, please.

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/