Re: Fw: [isocpp-parallel] OOTA fix (via fake branch-after-load) discussion

[Jonas Oberhauser]

Am 11/7/2023 um 5:44 PM schrieb Paul E. McKenney:
> On Tue, Nov 07, 2023 at 03:57:45AM -0600, Segher Boessenkool wrote:
> > On Mon, Nov 06, 2023 at 06:16:24PM -0800, Paul E. McKenney wrote:
> >
> > > I am very much against incurring real overhead to solve an issue that is
> > > an issue only in theory and not in practice.  I wish I could confidently
> > > say that my view will prevail, but...


Where to complain to to increase the chance of your view prevailing?


> >                                                           If what you
> > are writing has a constrained scope, or a limited impact, or both, you
> > can ignore this "we'll deal with it later if/when it shows up".  But a
> > compiler does not have that luxury at all: it has to make correct
> > translations from source code to assembler code (or machine code
> > directly, for some compilers), or refuse to compile something.  Making
> > an incorrect translation is not an option.
> But in this case, it would be most excellent if compiler practice were
> to follow theory.  Because the theory of avoiding OOTA without emitting
> extraneous instructions is quite simple:
>
> 	Avoid breaking semanitic dependencies.


The problem with that is that C, unlike LKMM, doesn't use a ppo-based model.

So there's no notion of "breaking a dependency" that could be applied to 
define what it means "not to break" semantic dependencies.

But the solution is actually simpler. Just add the axiom (proposed by 
Viktor):

    There are no OOTA behaviors


> 4.	Semantics of volatile.	Perhaps the current state is the best
> 	that can be hoped for, but given that the current state is a
> 	few vague words in the standard in combination with the fact
> 	that C-language device drivers must be able to use volatile
> 	to reliably and concurrently access memory shared with device
> 	firmware, one would hope for better.


Is it really so bad? I think the definition in the manual is quite 
precise, if confusing. (volatiles are visible side effects and must 
therefore have the same program order in the abstract machine and in the 
implementation, and that's pretty much it).

There should just be a large explanatory note about what it implies and 
what it doesn't imply.


> 5.	UB on signed integer overflow.	Right now, the kernel just
> 	forces wrapping, which works, so maybe we don't really care
> 	all that much.	But at this point, it seems to me that it was a
> 	mistake for the language to have failed to provide a means of
> 	specifying signed integers that wrap (int_wrap?).  (Yes, yes,
> 	you can get them by making an atomic signed int, but that is
> 	not exactly an ergonomic workaround.)

What I don't understand is why they didn't make signed integer types 
wrap when they became two's complement.