This is the mail archive of the gcc-patches@gcc.gnu.org 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: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)


On Fri, Aug 23, 2019 at 02:43:42PM -0700, Jason Merrill wrote:
> On 8/23/19 9:32 AM, Marek Polacek wrote:
> > This patch implements another C++20 feature, partially deprecating volatile.
> > You can read the proposal here: <http://wg21.link/p1152r4>.  I encourage
> > interested people to read the background in <http://wg21.link/p1152r0> which
> > provides a lot of interesting volatile-related information.
> > 
> > Note that P1152R4 differs slightly from what's now in the standard: the mention
> > of "non-class type" was dropped.  (Assignment to objects of a class type is
> > defined by the copy/move assignment operator.)
> > 
> > The gist is that expressions that involve both load and store of a volatile
> > lvalue, such as ++ or += are deprecated, as are volatile-qualified parameter
> > and return types.  Chained assignments of the form "a = b = c" are also
> > deprecated because there's some confusion as to if 'b' is re-read before storing
> > the value to 'a' (GCC claims not to do it).  See Annex D [depr.volatile.type].
> > 
> > [expr.ass] further says that "A simple assignment whose left operand is of
> > a volatile-qualified type is deprecated unless the assignment is either
> > a discarded-value expression or appears in an unevaluated context."
> > and therein lies the rub.  When parsing/building the MODIFY_EXPR, we don't know
> > if the assignment's value is going to be discared.  We only know that after
> > mark_discarded_use has run, which for expression-statements takes place in
> > finish_expr_stmt -> conver_to_void, and that is quite late.
> 
> It wouldn't work to warn in mark_[lr]value_use?

My worry is that we might be calling those too often and generate redundant
diagnostics but I'll have to play with that a bit before I can say for sure.

Marek


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