Re: Undefined behaviour in C23

Martin Ward <mwardgkc@gmail.com> writes:
[actually, John Levine writes:]
>[When a language is 50 years old and there is a mountain of legacy code that
>they really don't want to break, it accumulates a lot of cruft.


But there is a very vocal group of people who argue that programs that
exercise undefined behaviour are already broken (and they often use
stronger words that that) and that compilers are allowed to (and
should) compile them to code that behaves differently than earlier
compilers that the new compiler supposedly is just a new version of.


So according to this argument, when something that the legacy code
does is declared as undefined behaviour, this breaks this program.


And the practice is that the people in C compiler maintenance reject
bug reports as RESOLVED INVALID when the code exercises undefined
behaviour, even when the code works as intended in earlier versions of
the compiler and when the breakage could be easily fixed (e.g., for
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66804> and
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65709> by using movdqu
instead of movdqa).


But they not always do so: The SATD function from the SPEC benchmark
464.h264ref exercises undefined behaviour, and a pre-release version
of gcc-4.8 generated code that did not behave as intended. The
release version of gcc-4.8 compiled 464.h264ref as intended (but later
a similar case that was not in a SPEC program
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66875> was rejected as
RESOLVED INVALID). When I brought this up, the reactions reached from
flat-out denial that it ever happened (despite it being widely
publicized <https://lwn.net/Articles/544123/>) through a claim that
the "optimization" turned out to have no benefit (and yet the similar
case mentioned above still was "optimized" in a later gcc version) to
a statement along the lines that 464.h264ref is a relevant benchmark.


The last reaction seems to be the most plausible to me. The people
working on the optimizers tend to evaluate their performance on a
number of benchmarks, i.e., "relevant benchmarks", and of course these
benchmarks must be compiled as intended, so that's what happens. My
guess is that "relevant benchmarks" are industry standard benchmarks
like SPEC, but also programs coming from paying customers.


They also have their test suites of programs for regression testing,
and any behavioural change in these programs that is visible in this
regression testing probably leads to applying the optimization in a
less aggressive way.


How do tests get added into the regression test suite? Ideally, if
somebody reports a case where a program behaves in one way in an
earlier version of the same compiler and differently in a later
version, that program and its original behaviour should usually be
added to the test suite
<https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>, but in gcc
this does not happen (see the bug reports linked to above).
Apparently gcc has some other criteria for adding programs to the test
suite.


So, is C still usable when you do not maintain one of those programs
that are considered to be relevant by C compiler maintainers? My
experience is that the amount of breakage for the code I maintain has
been almost non-existent in the last 15 years. A big part of that is
that we use lots of flags to tell the compiler that certain behaviour
is defined even if the C standard does not define it. Currently we
try the following flags with the versions of gcc or clang that support
them:


-fno-gcse -fcaller-saves -fno-defer-pop -fno-inline -fwrapv
-fchar-unsigned -fno-strict-aliasing -fno-cse-follow-jumps
-fno-reorder-blocks -fno-reorder-blocks-and-partition
-fno-toplevel-reorder -fno-trigraphs -falign-labels=1 -falign-loops=1
-falign-jumps=1 -fno-delete-null-pointer-checks -fcf-protection=none
-fno-tree-vectorize -mllvm=--tail-dup-indirect-size=0


Some of these flags just disable certain transformations; in those
cases there is no flag for defining the language in the way that our
program relies on, but only the optimization transforms it in a way
that is contrary to our intentions. In other cases, in particular
-fno-tree-vectorize, using the flag just avoids slowdowns from the
"optimization".


Another big part of the lack of breakage experience is probably the
code in the regression tests of the compiler, whatever the criteria
are used for including this code. I.e., our code rides in the
slipstream of this code.


>On the other hand, there's the python approach in which they deprecate and
>remove little used and crufty features, but old python code doesn't work any
>more unless you go back and update it every year or two. -John]


Is it so bad with Python? From what I read, after the huge problems
that Python had with migrating the existing code base from Python2 to
Python3 (where Python3 was intentionally not backwards compatible with
Python2), they had decided not to make backwards-incompatible changes
to the language in the future.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/
[python may say they're not making backwards-incompatible changes
but 3.13 will delete some modules I use from the standard library.
It's not a huge problem to find copies of them and install them
locallb, but if I don't, my scripts will break. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.