Re: Computer architects leaving Intel...

On Fri, 6 Sep 2024 13:37:13 +0000, Tim Rentsch wrote:

Thomas Koenig <tkoenig@netcologne.de> writes:
>

Thomas Koenig <tkoenig@netcologne.de> schrieb:
>

"Don't do this" or "don't do that" is not sufficient.  Maybe you,
together with like-minded people, could try formulating some rules
as an extension to the C standard, and see where it gets you.
Maybe you can get it published as an annex.

>
Hm... putting some thought into it, it may be a good first step
to define cases for which a a diagnostic is required;  maybe
"observable error" would be a reasonable term.
>
So, put "dereferencing a NULL pointer shall be an observable
error" would make sure that no null pointer checks are thrown
away, and that this requires a run-time diagnostic.
>
If that is the case, should dereferencing a member of a struct
pointed to by a null pointer also be an observable error, and
be required to be caught at run-time?
>
Or is this completely the wrong track, and you would like to do
something entirely different?  Any annex to the C standard would
still be constrained to the abstract machine (probably).

>
The idea is not to make more of the language defined but to give
less freedom to cases of undefined behavior.  (It might make
sense to define certain cases that are undefined behavior now but
that is a separate discussion.)  Let me take an example from
another of your postings:
>
  int a;
>
   ...
>
  if (a > a + 1) {
    ...
  }
>
>
Stipulating that 'a' has a well-defined int value, what behaviors
are allowable here?
>
If a < INT_MAX, the behavior is the same as replacing the if()
test with 'if(0)'.  If the compiler can accurately deduce that
the condition 'a < INT_MAX' will hold in all cases then the if()
can be optimized away accordingly.
>
If a == INT_MAX, one possibility is that code is generated to
evaluate the addition and the comparison, and the if-block is
either evaluated or it isn't, depending on the outcome of the
comparison.  Important:  the compiler is disallowed from drawing
any inferences based on "knowing" the result of either the
addition or the comparison;  code must be generated under a "best
efforts" umbrella, and whatever the code does dictates whether
the if-block is evaluated or not, with the compiler being
forbidden to draw any conclusions based on what the result will
be.
>
If a == INT_MAX, it also should be possible for the addition to
abort the program.  Here again the compiler is disallowed from
drawing any inferences based on knowing this will happen.  To
make this work the rule allowing "UB to travel backwards in time"
must be revoked;  unless a compiler can accurately deduce that a
given piece of code cannot transgress into UB then other code in
the program must not be moved (either forwards or backwards) past
the possibly-not-well-defined code segment.

It is also possible if a == INT_MAX that the exception will
transfer control to a signal handler to do some SW orchestrated
recovery.

Let me be clear that I have not thought through all the details
about exactly what the rules are or how they might be put into
effect.  Hopefully though my comments here give you a better
sense of the direction meant to be suggested.