This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

Hi Jason and Andrew,

On Mon, Feb 04 2019, Jason Merrill wrote:
> On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor <> 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.

All right then, I was wondering what the FE specific parts would be too
but did not have a reason to doubt it.

Andrew, the word has it that Paul McKenney has expressed interest to
co-mentor this Google Summer of Code project, would you be willing to
join him?  The proposal is still copied below for your convenience.



> Jason
>> Anybody else interested in getting involved?
>> Any other suggestions/comments?
>> Thank you very much in advance,
>> Martin
>> -------------------- 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 [1].
>> So what is to be done?  One proposal [2] 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 [3].  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 [2].
>> [1]
>> [2]
>> [3]
>> ---
>> Ramana
>> -------------------- End of forwarded message --------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]