Date: Thu, 09 Jun 2022 03:16:50 +0000
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.
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_lists.isocpp.org >>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2022-06-09 03:16:54