Re: Computer architects leaving Intel...

Thomas Koenig <tkoenig@netcologne.de> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>

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.

>
That sentece makes no sense to me.
>
Behavior is defined by the standard, by the compiler documentation,
by other standards (such as OpenMP) or it is undefined.
>
"Giving less freedom" has no difference from defining.

I use the term "undefined behavior" in the same sense that the C
standard does.  For example, if a particular C implementation
supports the POSIX extensions to printf(), including documenting
them, using those extensions still falls under the heading of
undefined behavior, support and documentation not withstanding.

The idea is to define a new classification, perhaps "limited
undefined behavior", that gives more freedom than "unspecified
behavior" but not nearly as much as "undefined behavior" does
now.

(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.

>
After thinking about this for a time, what you want looks a lot
like volaitle.

That's a good insight.  Certainly there are aspects of what I
have proposed that are similar to how volatile works.

Is there any requirement that you can think of that would not
be fullfilled with "volatile int a"?
>
Is there anything with "volatile int a" that you do not want?

Something being volatile has consequences only in reference to
objects, and only when a memory access (either read or write) is
requested.  There are no such things as volatile values.  What
we're looking for here is constraints on operations, not on
memory accesses.  In a sense one might say what we want is
"volatile operators":  similar in concept to how volatile works,
but in a different area of language semantics.

Also there are aspects of 'volatile' is defined now that are too
lax for what I think "volatile operators" need to do.  However
that is a fine point, I mention it only for completeness.

If volatile is close to what you want, then this would be
straightforward to incorporate into an existing compiler such as
gcc, just add an option which declares every variable in the C
front end volatile, weed out the resulting bugs (yes, that is a
mixed metaphor) and be done.

Like I said, it isn't the variables, it's the operators.  Maybe
though you have a good idea there, looking at how volatile is
handled in gcc or clang might give some useful ideas about how to
implement volatile operators.