I grilled an LLM for a bit to see if it could justify the old forward progress rule. The only thing I got that passed the smell test was that it’s useful for the optimizer to be able to optimize:

    messy_pure_computation();
    some_atomic.store(1, relaxed);

by moving the store before the computation. (Stronger stores would require additional analysis.)

I admit I’m unconvinced that this is particularly useful.

(I got many other ideas that did not pass my personal smell test.)

▲ raphlinus 4 hours ago | parent | next [-]

You will find the answer you seek not from an LLM, but from the talk Forward Progress Guarantees in C++ by Olivier Giroux at CppNow 2023. It's a long talk, with lots of details about forward progress, but I've set the timestamp[1] to the infinite loop bit.

[1]: https://youtu.be/g9Rgu6YEuqY?si=_l9JwKhjvIdFEDEX&t=3819

▲ mitxela 2 hours ago | parent | prev [-]

I thought it was generally so the compiler can merge two computation loops without proving if one of them runs forever .

	▲	murderfs 14 minutes ago \| parent [-]
		Correct. See N1528: "Why undefined behavior for infinite loops?" https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1528.htm