Re: [RFC][PATCH 0/5] arch: atomic rework

[Paul E. McKenney]

On Thu, Feb 20, 2014 at 10:32:51AM -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > You really need that "consume" to be "acquire".
> 
> So I think we now all agree that that is what the standard is saying.
> 
> And I'm saying that that is wrong, that the standard is badly written,
> and should be fixed.
> 
> Because before the standard is fixed, I claim that "consume" is
> unusable. We cannot trust it. End of story.

We get exactly those same issues with control dependencies.

The example gcc breakage was something like this:

	i = atomic_load(idx, memory_order_consume);
	x = array[0 + i - i];

Then gcc optimized this to:

	i = atomic_load(idx, memory_order_consume);
	x = array[0];

This same issue would hit control dependencies.  You are free to argue
that this is the fault of ARM and PowerPC memory ordering, but the fact
remains that your suggested change has -exactly- the same vulnerability
as memory_order_consume currently has.

> The fact that apparently gcc is currently buggy because it got the
> dependency calculations *wrong* just reinforces my point.
> 
> The gcc bug Torvald pointed at is exactly because the current C
> standard is illogical unreadable CRAP. I can guarantee that what
> happened is:
> 
>  - the compiler saw that the result of the read was used as the left
> hand expression of the ternary "? :" operator
> 
>  - as a result, the compiler decided that there's no dependency
> 
>  - the compiler didn't think about the dependency that comes from the
> result of the load *also* being used as the middle part of the ternary
> expression, because it had optimized it away, despite the standard not
> talking about that at all.
> 
>  - so the compiler never saw the dependency that the standard talks about

No, the dependency was in a cancelling arithmetic expression as shown
above, so that gcc optimized the dependency away.  Then the ordering
was lost on AARCH64.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448

> BECAUSE THE STANDARD LANGUAGE IS PURE AND UTTER SHIT.
> 
> My suggested language never had any of these problems, because *my*
> suggested semantics are clear, logical, and don't have these kinds of
> idiotic pit-falls.
> 
> Solution: Fix the f*cking C standard. No excuses, no explanations.
> Just get it fixed.

I agree that the standard needs help, but your suggested fix has the
same problems as shown in the bugzilla.

							Thanx, Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/