This is the mail archive of the
mailing list for the GCC project.
Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
- From: Jason Merrill <jason at redhat dot com>
- To: Martin Jambor <mjambor at suse dot cz>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, "Paul E. McKenney" <paulmck at linux dot ibm dot com>, Ramana Radhakrishnan <ramana dot r at gmail dot com>, Nathan Sidwell <nathan at acm dot org>
- Date: Mon, 4 Feb 2019 12:09:32 -0500
- Subject: Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
- References: <email@example.com>
On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor <firstname.lastname@example.org> wrote:
> I have received the following idea for a Google Summer of Code project,
> see the quotation from Paul McKenney below (I do not know myself where
> exactly it is from). I consider memory consistency models a very tough
> topic and so am doubly reluctant to just post it to wiki without having
> a mentor for it. On the other hand, with the right mentors it
> definitely can be quite a remarkable project with a big potential.
> Paul, this may come as a surprise for you, but would you be willing to
> (co-)mentor such a project if there is a student brave enough to
> undertake it?
> C++ front-end guys, would you please consider co-mentoring this project
> if Paul was willing to do so?
I wouldn't expect this project to touch the C++ front-end at all; any
compiler work would all be in the middle/back-end. There's some
previous discussion of these issues at
So I'd suggest pinging Andrew Macleod.
> Anybody else interested in getting involved?
> Any other suggestions/comments?
> Thank you very much in advance,
> -------------------- Start of forwarded message --------------------
> Hi Martin,
> I don't think I have a mentor for this yet though I wonder if Paul McKenney
> could be persuaded for this from the memory model side and someone familiar
> with the C++ frontend on the GCC side ?
> <quote Paul>
> One could argue that compilers in fact implement the C and C++
> memory_order_consume facility. However, all known compilers do so by
> promoting it to memory_order_acquire, which on weakly ordered systems
> can result in unnecessary memory-barrier instructions on your fastpaths,
> which might not be what you want. The reason for the promotion to
> memory_order_acquire is the difficutlies faced by compiler writers when
> attempting to trace dependencies at the C/C++ source-code level. In fact,
> there is a proposal to temporarily deprecate memory_order_consume .
> So what is to be done? One proposal  restricts dependency chains
> to cases where it is difficult for the compiler to break them, and
> further requires that pointer variables carrying dependencies be marked.
> (This proposal also includes prototype wording for the C++ standard,
> a number of litmus tests, and some discussion.) Such marking might not
> go down well with the Linux kernel community, which has been carrying
> dependencies in unmarked variables for more than 15 years, so there is
> further informal proposal asking C and C++ implementations to provide a
> command-line option forcing the compiler to treat any pointer variable
> as if it had been marked. (Why informal? Because command-line options
> are outside of the scope of the standard.)
> There is a prototype implementation that obtains the functionality of
> memory_order_consume without actually using memory_order_consume, which
> is briefly described in a recent C++ working paper . However, the
> committee was not all that happy with this approach, preferring marking
> of a single pointer variable to maintaining a separate variable to carry
> the dependency.
> It would therefore be quite desirable to have an implementation that
> allowed pointers to be marked as carrying dependencies, that avoided
> the specified dependency-breaking optimizations on such pointers, and
> that provided a command-line switch that caused the compiler to treat
> all pointers as if they were to marked .
>  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
>  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
>  http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
> -------------------- End of forwarded message --------------------