Re: Undefined Behavior Optimizations in C

Jon Chesterfield <jonathanchesterfield@gmail.com> schrieb:
>> So before we decide if UB optimizations are actually allowed by the
> standard we need to decide what "ignoring the situation completely
> with unpredictable results" actually means.
>
> [1] https://port70.net/~nsz/c/c89/rationale/
>
> Lucian
>
> WG14 are aware of UB optimising compilers and could have steered away from
> this path, but haven't. It's been decades now. The pointer provenance work
> seeks to apply aliasing rules even more aggressively. GCC and clang are
> both pursuing faster codegen via exploiting undefined behaviour.
>
> C, the WG14 ISO defined language, as implemented by the primary open source
> toolchains, is thus unfit for my purposes.


This whole discussion is a bit weird.


The C standard, like any programming language standard, is a
specification. Compiler writers promise to keep their end of the
bargain by translating code to machien language according to that
specification (modulo bugs). A programmer who uses the language
according to that specification can be sure that this is translated
correctly (again, modulo bugs).


Compilers are required to document implementation-defined behavior,
and it is also possible to document undefined behavior; a
documented instance of undefined behavior is an extension.


For example, a program which uses #include <unistd.h> (where in
fact another standard, POSIX, is referenced) or using __builtin_clz
(a gcc extension taken up by other compilers) invokes undefined
behavior according to the C standard. There is nothing wrong with
that, provided the programmers sticks to compilers where it is
documented to be supported.


There is another class of undefined behavoor, that which is the result
of an erroneous construct. It appears that some people like to violate
the specifications (both the C standard and the compiler's
documentation, or other standards) and expect consistent results
according to their wishes. Or, to put it slightly differently, they
assume some sort of unwritten super specification that should apply in
addition to the other specifications.


There is in fact no such specification, and it is unclear if peple
who think so could agree on what exactly it should and should
not contain.


And people who have such an unspecified specification in mind then are
then hurt, indignant and sometimes downright offensive to people who
point out that compiler writers follow the written and
well-established specifications of the standards, and that something
that happened by accident in earlier revisions of a compiler has
changed.


> I'm not clear what use that language has.


Either you know very little knowledge of the software currently used
(did you ever hear of a piece of software called the "Linux kernel"?)
or you are engaging in hyperbole. I strongly suspect the latter.


If C is indeed the right sort of language to write large programs in
is quite another question, in which a strong argument against C can
indeed be made.


> C, the typed assembler of ye olde times, is a profoundly useful language.
> One just can't use GCC or clang to build it reliably.


You mean without a lot of the optimizations of the last (almost)
fifty years?


> It annoys me intensely that the type aliasing rules capture something a
> whole program optimising compiler can usually work out for itself anyway,


Link-time optimization, while highly useful, currently has severe
scaling issues. This is an area where advances would be really
useful (if implemented in production compilers).


> while preventing me from reading 128bit integers from the same memory I
> fetch_add 32bit integers into.


Not clear what exactly you want to do this.

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