Thank you Michael
I have put in the D number and formatted the title more or less according to what you proposed.
I also put in the date of the next mailing for the date. Is this ok or should I use another date? The date the number was pulled?
If anyone wishes to be added/removed to/from the contributors list just contact me.

If this is something that concerns you I would like an example as Arthur mentioned. If you can give an excerpt from a codebase where this would pose a problem I would love to include it in the paper. Even though I would think that avr-libc, cmcis and the raspberry pi nano libraries would have a pretty wide audience, I agree that it would be better to show a wider impact.

If anyone can come up with a formulation of the "We don't know what we are getting.If it is possible to get atomicity we would love it, but we know that is rarely the case" sentence that doesn't sound completely idiotic, I'll credit whoever can come up with it with coauthor credits. :D


Den man. 22. feb. 2021 kl. 17.57 skrev Michael Wong <>:
The paper number is D2327R0.
We should improve the headings in the paper as a first feedback.
Use something like this:




ISO JTC1/SC22/WG21: Programming Language C++


SG14, EWG, WG21




Reply to:

Revision History

Thanks. Regards

More Feedback coming.

On Fri, Feb 19, 2021 at 8:08 AM Ronan Keryell via SG14 <> wrote:
On 2/17/21 5:36 PM, Paul M. Bendixen via SG14 wrote:

> So I've tried to incorporate the feedback given.
> I know I can have a tendency to ramble a bit in text so if the
> proposal is still not clear enough, please let me know.

That looks good.

> I've added a single example of usage in a library "from the wild", if
> further examples are required, I would like to know were they might
> fit.
Good example.

Since it looks like LaTeX, perhaps you could improve the presentation of
the code samples with

some example...

> I haven't added the "what do we expect from atomicity of compound
> expressions" section, as I frankly do no know what to expect other
> than it not breaking the hal that is often times _more_ important than
> the standard library.

I guess that in this area at least we do not care about breaking the
ABI. :-)

But perhaps a non normative note about no expectation of atomicity or
whatever could be useful.

> I'm still looking for any feedback this group may have.

I asked internally and the only feedback was "volatile is the problem,
not only this detail"... :-)
Since it is another discussion, I think that as volatile is in the
language and the compatibility with C is a selling point for C++, we
should keep the same behavior, even if it is blurry at the first place.

Anyone using volatile should be aware there are dragons here and be
aware of some hardware details and compiler implementation details while
not expecting too much.

In my FPGA company "x &= y" means do "x = (x & y)" with x only evaluated
once, and with x being volatile, first make a read access to x via an
AXI-MM bus to "something", do the computation, make a write access via
an AXI-MM bus to the same "something" or "something else".

There is no assumption about a load-modify-store instruction because,
well, there is no... instruction, just logic gates... ;-)

At the end there are only logic gates executing something equivalent to
the C++ program.

What will respond to reading x or writing x on some bus will depend on
some bigger picture depending for example on some RTL code
(Verilog/VHDL) outside of the scope of the C++ program.

Ronan KERYELL, Xilinx Research Labs / San José, California.
SG14 mailing list

• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//