Re: Computer architects leaving Intel...

George Neuner <gneuner2@comcast.net> schrieb:

I'm not going to argue about whether UB in code is wrong.  The
question I have concerns what to do with something that explicitly is
mentioned as UB in some standard N, but was not addressed in previous
standards.
>
Was it always UB?  Or should it be considered ID until it became UB?

Can you give an exapmple?

I would say this really depends on the circumstances.  If it is
something left unspecified by earlier standards, and put into the
list of undefined behavior as a clarification, that is one thing.

If it is something that was previosly well-defined and then made
into undefined behavior, that is another thing; I would then
likely consider it a bug in the standard (but again, depending
on the circumstances).

It does seem to me that as the C standard evolved, and as more things
have *explicitly* become documented as UB, compiler developers have
responded largely by dropping whatever the compiler did previously -
sometimes breaking code that relied on it.

There's a reason that there is a "porting to" file for each release
of gcc; in a way, each release can be considered a new compiler.

As an example, here's an entry from
https://gcc.gnu.org/gcc-13/porting_to.html :

# Fortran language issues

# Behavior on integer overflow

# GCC 13 includes new optimizations which may change behavior on
# integer overflow. Traditional code, like linear congruential
# pseudo-random number generators in old programs and relying on
# a specific, non-standard behavior may now generate unexpected
# results. The option -fsanitize=undefined can be used to detect
# such code at runtime.
#
# It is recommended to use the intrinsic subroutine RANDOM_NUMBER for
# random number generators or, if the old behavior is desired, to use
# the -fwrapv option. Note that this option can impact performance.

Integer overflow on multiplication had always been illegal in
Fortran (prohibited by "shall not"), but it had widely been used
anyway.  That was a though one...