Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здесь видимо следующая логика: i не отрицательное, и только инкрементируется, следовательно отрицательным без прохода по UB оно никак стать не может, поэтому имеем право заменить i>=0 на true.
EP>Не думаю что зависит от количества итераций. Ибо даже если начинать с i=0 — в генерируемом коде всё равно безусловный jmp.

Да, согласен. Я забыл, что в неудачном варианте было i>0, и не проверил этот от нуля.
У GCC, -O2 и выше без -fno-strict-overflow приводит к удалению проверки.
У Clang, -Og уже достаточно для такого эффекта.

N>>Ну я давно говорю, что семантика переполнения должна быть управляема контекстом — и ни знаковая с "программист должен сам", ни беззнаковая с модулем не должны быть единственными,

EP>Там где скорость не важна — очевидно можно решить пользовательскими типами, а-ля safe int, saturated int, etc. Там где важна — нужна поддержка железа.

Пользовательские типы — да, можно и сейчас, но это от бедности. Для типов, имеющих диапазоны значений не согласно задаче, а согласно железу — лучше задавать контекстом.
Поддержка железа давно доступна в нормальных компиляторах

N>>а умолчанием вообще должна быть неотложная генерация ошибки.
EP>Было бы неплохо. Например как trap при делении на ноль.

Ну этот trap в Unix неудобно ловить.
Я предпочитаю явное исключение (C++) или простановку флага.