On Sun, Jun 06, 2021 at 06:36:51AM -0500, Segher Boessenkool wrote:

On Fri, Jun 04, 2021 at 01:40:42PM -0700, Paul E. McKenney wrote:

quoted

On Fri, Jun 04, 2021 at 02:53:01PM -0500, Segher Boessenkool wrote:

quoted

On Fri, Jun 04, 2021 at 11:55:26AM -0700, Paul E. McKenney wrote:

quoted

On Fri, Jun 04, 2021 at 11:40:47AM -0500, Segher Boessenkool wrote:

quoted

My point is that you ask compiler developers to paint themselves into a
corner if you ask them to change such fundamental C syntax.

Once we have some experience with a language extension, the official
syntax for a standardized version of that extension can be bikeshedded.
Committees being what they are, what we use in the meantime will
definitely not be what is chosen, so there is not a whole lot of point
in worrying about the exact syntax in the meantime.  ;-)

I am only saying that it is unlikely any compiler that is used in
production will want to experiment with "volatile if".

That unfortunately matches my experience over quite a few years.  But if
something can be implemented using existing extensions, the conversations
often get easier.  Especially given many more people are now familiar
with concurrency.

This was about the syntax "volatile if", not about the concept, let's
call that "volatile_if".  And no, it was not me who brought this up :-)

I agree that it is likely that the syntax "volatile if" would be at best
a very reluctantly acquired taste among most of the committee.  But some
might point to the evolving semantics of "auto" as a counter-example,
to say nothing of the celebrated spaceship operator.  Me, I am not
all that worried about the exact syntax.

quoted

quoted

quoted

Which is exactly why these conversations are often difficult.  There is
a tension between pushing the as-if rule as far as possible within the
compiler on the one hand and allowing developers to write code that does
what is needed on the other.  ;-)

There is a tension between what users expect from the compiler and what
actually is promised.  The compiler is not pushing the as-if rule any
further than it always has: it just becomes better at optimising over
time.  The as-if rule is and always has been absolute.

Heh!  The fact that the compiler has become better at optimizing
over time is exactly what has been pushing the as-if rule further.

The underlying problem is that it is often impossible to write large
applications (such as the Linux kernel) completely within the confines of
the standard.  Thus, most large applications, and especially concurrent
applications, are vulnerable to either the compiler becoming better
at optimizing or compilers pushing the as-if rule, however you want to
say it.

Oh definitely.  But there is nothing the compiler can do about most
cases of undefined behaviour: it cannot detect it, and there is no way
it *can* be handled sanely.  Take for example dereferencing a pointer
that does not point to an object.

Almost.

The compiler's use of provenance allows detection in some cases.
For a stupid example, please see https://godbolt.org/z/z9cWvqdhE.

Less stupidly, this sort of thing can be quite annoying to people trying
to use ABA-tolerant concurrent algorithms.  See for example P1726R4
[1] (update in progress) and for an even more controversial proposal,
P2188R1 [2].  The Lifo Singly Linked Push algorithm described beginning
on page 14 of [1] is a simple example of an ABA-tolerant algorithm that
was already in use when I first programmed a computer.  ;-)

							Thanx, Paul

[1]	http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1726r4.pdf
[2]	http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2188r1.html