There is no hope of getting the committee to accept any form of volatile as
legitimate; it has been captured by optimizationists for many years now,
and the prospect of optimizing away access to volatile variables is so
delicious to them that no practical use can be tolerated.

You are correct in your desire to use volatile as a means of allowing
debuggers to modify variables. Volatile is not restricted to I/O (unless
the wording had been changed in recent years). Volatile means that the
variables may be modified externally to the program, and therefore every
access to it must be performed as if its value is unknown: it must have
some location (a register is fine), and reads must read from that location
and writes must write to that location.

The committee will never agree to that, though.

On Wed, Jun 8, 2022, 11:16 PM Ryan P. Nicholl via Std-Proposals <
std-proposals_at_[hidden]> 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.
>
> 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.
>
> 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.
>
> 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.
>
> --
> Ryan P. Nicholl
> Tel: (678)-358-7765
>
>
> ------- Original Message -------
> On Wednesday, June 8th, 2022 at 11:03 PM, Ryan P. Nicholl via
> Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> Also, volatile bool cannot be accessed by a signal handler, that is a race
> per the c++ standard?
>
>
> -------- Original Message --------
> On Jun 8, 2022, 23:02, Ryan P. Nicholl < rnicholl_at_[hidden]> wrote:
>
>
> My understanding is that volatile applies not only to signal handlers but
> also debuggers and other programs writing to the variable. Is that wrong?
>
> When did the understanding of volatile change?
>
>
> -------- Original Message --------
> On Jun 8, 2022, 21:08, Thiago Macieira via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>
> On Wednesday, 8 June 2022 14:46:58 PDT Ryan P. Nicholl via Std-Proposals
> wrote:
> > Hello. I just wanted to point out a usage of volatile that I don't think
> > should be deprecated. Namely, the use of volatile on a function argument.
>
> That's a clear one that should be deprecated. For architectures that pass
> parameters in the stack, the address is practically arbitrary, is
> definitely on
> the stack, and is usually exclusive to the callee. For architectures that
> pass
> parameters in registers, there's simply no way to have a volatile register.
>
> > This may sound weird but it can be useful to create a parameter like
> > 'volatile bool collect_debug_info = false' that gets passed down to
> > functions that get called by the function. The function is called with it
> > always false so if the function is inlined the compiler will elide all
> the
> > instances of it being checked. Simply editing the variable in the
> debugger
> > can be useful to collect information this way for a specific execution
> > without having to do anything more complicated. I would therefore suggest
> > this be either 1. un-deprecated, possibly as a defect report for C++20 or
> > 2. a new keyword or attribute specifically for values that are intended
> to
> > be changed in a debugger so that it still warns people misusing it for
> > threading. I'm also unsure about the value of deprecating += and such,
> but
> > it's definitely understandable.
>
> You're talking about optimisations, which means QoI. If you don't want the
> compiler to elide that variable, then please talk to your compiler vendor.
> None of your needs are related to the volatileness of said variable. And
> your
> compiler is allowed to remove that volatile variable as you've described
> under
> the "as-if" optimisation rule because it clearly cannot be observed by
> other
> threads of execution or even signal handlers. The only reason you're
> getting
> the behaviour you want is because when compilers see volatile, they usually
> shut their brains off and stop optimising well.
>
> volatile variables only make sense if you're doing MMIO or similar
> technologies where the acts of reading or writing are, themselves,
> observable.
> Reading of stack, heap and regular global variables is not an observable
> act.
>
> --
> 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
>