On Thu, Jun 9, 2022 at 10:16 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Jun 9, 2022 at 9:34 AM Ryan P. Nicholl via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > There is no real reason we should need to add a new feature for what
> already legitimately works today.
>
> That a thing "works" does not mean it is supposed to work this way. Or
> that it makes some kind of sense. See below.
>
> > Existing behavior of volatile was fine.
>
> My general understanding of the reasons for the deprecation of various
> uses of `volatile` was to actually *rationalize* the feature. That is,
> to make it make sense and to make sure people understand that it isn't
> meant to do a lot of things they thought they were doing with it.
>
> The principal problem with `volatile` is that it got used for a lot of
> things that it was never meant to do. People used it for atomics
> because certain platforms guaranteed atomic access if you used basic
> types that were `volatile`. That was *never* what it was meant to do
> and if you've only ever programmed on platforms where that's true, you
> will get a very rude awakening when you're forced to use ARM and find
> all your "atomic" code stops working.
>
> This debugging trick is *also* not what `volatile` was meant to do.
> And as others have pointed out, it's not even behavior that is
> required *by the standard*. Since the address of this variable is
> under the complete control of the runtime, and its address is never
> given out to any code that the compiler cannot see, the compiler can
> be 100% certain that no external process can manipulate its value.
>


And yet the existence of debuggers disproves that "100% certain".



>
> You might consider this all to be academic. But real programmers need
> to be able to read someone else's C++ and divine what it is they're
> doing from that source code. Features like `volatile` which get used
> for a lot of disparate things that don't really make sense to be under
> the same umbrella exacerbate this situation. Making it clear that
> `volatile` is a means to interact with hardware storage that changes
> outside of the C++ object model and *nothing else* would help clean up
> the language.
>
> > The new definition of volatile is considered harmful. I would hope the
> compiler vendors have the sense to ignore this nonsense and keep the old
> behavior.
> >
> > -------- Original Message --------
> > On Jun 9, 2022, 00:20, Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> >
> > On Wednesday, 8 June 2022 20:16:50 PDT Ryan P. Nicholl via Std-Proposals
> > wrote:
> > > All compilers have debuggers, I don't see why we shouldn't be able to
> use
> > > e.g. "RelWithDebInfo" and then turn on a variable. I'm pretty sure the
> > > point of volatile is to eliminate the "as-if" rule for that particular
> > > variable, meaning a debugger should be allowed to change the value and
> the
> > > compiler respect that.
> >
> > That's an incorrect understanding. The language does need not take
> debugging
> > into account. The language defines how the program runs in the abstract
> machine
> > and volatile variables are I/O -- that is, they communicate with the
> outside
> > world.
> >
> > Under the "as-if" rule, if the compiler can prove that no I/O is
> possible,
> > then it *can* remove the volatile variable completely. That's what's
> happening
> > here.
> >
> > Global variables' address can be manipulated by the linker and placed in
> MMIO
> > regions, but if this is a possibility, then it is a contract between the
> > compiler and linker. That's not possible at all for stack (automatic
> storage)
> > variables, because there's no symbol for the linker to see in the first
> place.
> > Therefore, stack variables simply cannot be volatile. The language in the
> > standard was updated to clarify this situation, allowing the compilers
> to do
> > what should have been there all along.
> >
> > > A register can sure be volatile if it tells the compiler not to
> optimize
> > > away accesses or uses of that register, since the program's execution
> could
> > > be stopped and then a debugger simply rewrite the variable.
> >
> > There's no such thing as optimisation in the standard. If you want to
> control
> > what the optimiser of your compiler does or does not do, you need to
> discuss
> > it with your compiler vendor.
> >
> > Volatile *general purpose* registers make no sense. Some architectures
> do have
> > such a thing as I/O via registers, but compilers would never allocate a
> > variable to them, exactly because their use would have side-effect.
> Conversely,
> > compilers always use registers that don't have side-effects
> >
> > In a debugger, you could rewrite a variable, indeed, but that doesn't
> mean
> > your program will proceed to run correctly. The fact that a variable has
> a
> > current storage location somewhere your debugger can modify it does not
> mean
> > it's the only copy or that knowledge about it wasn't used in other
> > optimisations, prior to that point or after it.
> >
> > > I therefore see a perfectly legitimate way for a function parameter to
> be
> > > volatile? It certainly isn't useful to have stack volatiles for
> hardware
> > > programming but I have found the current implementation which allows
> it for
> > > communication between the debugger and the program to be quite useful.
> I'm
> > > not sure if the standard requires this behavior but I believe it does.
> >
> > I do not see it as legitimate. In your own words: "it isn't useful to
> have
> > stack volatiles for hardware programming". That's what volatile means
> today
> > and that's what the standard removed. Asking that it be reversed in a
> defect
> > report implies that this determination was wrong -- and it isn't.
> >
> > I see a perfectly legitimate use-case in what you're asking, though. You
> may
> > want to write a paper to give new meaning to the volatile keyword and
> address
> > your use-case, but that's not the same as what you're asking right now.
> >
> > I think your best bet is to discuss this with your compiler vendor and
> have
> > them provide a way for you to annotate somehow the sources and indicate a
> > variable must be spilled to memory and that the compiler must disable
> > optimisations that would assume its value stays unchanged while it is
> there.
> > They may decide to use the volatile marker as an extension to the
> standard.
> >
> > > Another case is that if we did have a "volatile sig_atomic_t" as a
> function
> > > parameter then we can pass that address to a global variable and
> install a
> > > signal handler that uses it. There's no rule against taking the
> address of
> > > a function argument and the calling convention is pretty irrelevant for
> > > this purpose. I would suppose a volatile argument behaves the same way
> as
> > > const, irrelevant for the caller but relevant for the definition.
> >
> > You don't need a volatile parameter for that. You can create a local
> variable
> > for it. They cost exactly the same.
> >
> > volatile atomics (not sig_atomic_t) are practically the only valid use of
> > volatile. And besides communicating with peripheral hardware via MMIO,
> > asynchronous signal handlers are the only remaining situation where even
> > volatile atomics make sense. They're subtly different to modifications
> by other
> > threads of execution. This is an area of the standard that still has some
> > rough edges.
> >
> > --
> > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> > Software Architect - Intel DPG Cloud Engineering
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
Be seeing you,
Tony