This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC][PATCH 0/5] arch: atomic rework
- From: Torvald Riegel <triegel at redhat dot com>
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Paul McKenney <paulmck at linux dot vnet dot ibm dot com>, Will Deacon <will dot deacon at arm dot com>, Peter Zijlstra <peterz at infradead dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, David Howells <dhowells at redhat dot com>, "linux-arch at vger dot kernel dot org" <linux-arch at vger dot kernel dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, "akpm at linux-foundation dot org" <akpm at linux-foundation dot org>, "mingo at kernel dot org" <mingo at kernel dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 20 Feb 2014 19:53:41 +0100
- Subject: Re: [RFC][PATCH 0/5] arch: atomic rework
- Authentication-results: sourceware.org; auth=none
- References: <CA+55aFyqLrj4d2TA+2aazRqXnbVsUvs0yaBL2D5rXF1G=Kiu_g at mail dot gmail dot com> <CA+55aFwsq5E8kMoEeHJJ1f2=+QAUCu_HndfPxHNz8fUBprS-jQ at mail dot gmail dot com> <1392740258 dot 18779 dot 7732 dot camel at triegel dot csb> <CA+55aFw7QYEMFs0BCxqRJW3Cz=tLbaku-tmN6hLXPKP9jbom7Q at mail dot gmail dot com> <1392752867 dot 18779 dot 8120 dot camel at triegel dot csb> <CA+55aFxQPxQ8WOaZL8yAqBA=Y4k2gDn4r4oepMyi0uL6XLzv3w at mail dot gmail dot com> <20140220040102 dot GM4250 at linux dot vnet dot ibm dot com> <CA+55aFwwscSzwTr+xRdirtTx7HzugmMY9HrDe0GBqNhn=AuNVA at mail dot gmail dot com> <20140220083032 dot GN4250 at linux dot vnet dot ibm dot com> <CA+55aFwfx==u7o1NZ66aPbkOgsvGqW3UscGqrQkGuzOkjSpm6Q at mail dot gmail dot com> <20140220181116 dot GT4250 at linux dot vnet dot ibm dot com> <CA+55aFwn9gXWVq_GL=tPPP63vsqs-9QB4ii4s06xqG4UscCV5w at mail dot gmail dot com>
On Thu, 2014-02-20 at 10:32 -0800, Linus Torvalds wrote:
> On Thu, Feb 20, 2014 at 10:11 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> >
> > You really need that "consume" to be "acquire".
>
> So I think we now all agree that that is what the standard is saying.
Huh?
The standard says that there are two separate things (among many more):
mo_acquire and mo_consume. They both influence happens-before in
different (and independent!) ways.
What Paul is saying is that *you* should have used *acquire* in that
example.
> 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.
Then we still have all the rest. Let's just ignore mo_consume for now,
and look at mo_acquire, I suggest.
> The fact that apparently gcc is currently buggy because it got the
> dependency calculations *wrong* just reinforces my point.
Well, I'm pretty sure nobody actually worked on trying to preserve the
dependencies at all. IOW, I suspect this fell through the cracks. We
can ask the person working on this if you really want to know.
> The gcc bug Torvald pointed at is exactly because the current C
> standard is illogical unreadable CRAP.
It's obviously logically consistent to the extent that it can be
represented by a formal specification such as the one by the Cambridge
group. Makes sense, or not?
> 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
>
> BECAUSE THE STANDARD LANGUAGE IS PURE AND UTTER SHIT.
Please, be specific. Right now you're saying that all of it is useless.
Which is arguable not true.
> 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.
Have you looked at and understood the semantics of the memory model
(e.g. in the formalized form) with mo_consume and related being ignored
(ie, just ignore 6.13 and 6.14 in n3132)?