Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sat, 07 Sep 2024 18:46:20 -0700
Organization: A noiseless patient Spider
Lines: 125
Message-ID: <864j6qncib.fsf@linuxsc.com>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me> <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me> <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me> <2024Aug31.170347@mips.complang.tuwien.ac.at> <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me> <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me> <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org> <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com> <86r0a2otte.fsf@linuxsc.com> <vb50cm$2uttr$1@dont-email.me> <vb58i5$303nc$1@dont-email.me> <868qw4oqd2.fsf@linuxsc.com> <vbgv7r$18q47$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sun, 08 Sep 2024 03:46:21 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f4e3787f228c748b74e6d718e0ca7324";
	logging-data="1680036"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+x0tqEQja1SHAhS/E7TMxr8OkzeUXthdo="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:2jbpc/4ISaqCBGnWtjzayoQRJUc=
	sha1:jIlDSbX+bm/4s+93rhxHF5+yaiA=
Bytes: 7028

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.