This is the mail archive of the
mailing list for the GCC project.
Re: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)
- From: Jason Merrill <jason at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 23 Aug 2019 14:43:42 -0700
- Subject: Re: C++ PATCH for P1152R4: Deprecating some uses of volatile (PR c++/91361)
- References: <20190823163230.GM14737@redhat.com>
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?