[Bug c++/79373] For loop optimization bug: condition ignored

["steven.p.pigeon at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79373

--- Comment #10 from Steven Pigeon <steven.p.pigeon at gmail dot com> ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Steven Pigeon from comment #7)
> > I do understand that this is what happens (the code is fixed by promoting
> > int32_t t=x to int64_t t=x) but the undefined behavior affects a variable
> > (and its associated comparison) that should not be affected by it.
> 
> The C++ standards defines undefined behavior as "behavior for which this
> International Standard imposes no requirements". No requirements. Not
> "doesn't affect things that you think shouldn't be affected". All bets are
> off.
> 
> There is no requirement for a compiler to do something you find
> unsurprising, or to limit the scope of the bug to parts of the code you
> expect to misbehave.

That's somewhat disconcerting, as some programs do rely on "expected undefined
behavior". For example,

val = ((state[0] * 1103515245) + 12345) & 0x7fffffff;

(found in
http://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/random_r.c;hb=glibc-2.15#l375
) will overflow (because if I understand correctly, in an int times int
operation, neither operands are promoted to a larger int type, and if overflow
occurs, it's undefined behavior). Should that mess up the program in
unpredictable ways? I'm trying to understand what exactly I'm fighting in order
to avoid further problems.