On 7/11/25 3:00 PM, Jakub Jelinek wrote:
On Fri, Jul 11, 2025 at 02:34:24PM -0400, Jason Merrill wrote:
But by the time we get to cp_fold, DECL_READ_P should have already been set
appropriately when we built the thing we're now folding. And calling
Clearly it hasn't been, otherwise I'd need to patch different spots as well.
mark_exp_read on foo(op0) won't mark op0 anyway; it doesn't recurse. I
don't see any regressions on Wunused* after
mark_exp_read recurses a little bit, on some simple cases.
E.g. COND_EXPR, COMPOUND_EXPR, casts, INDIRECT_REF, ...
Yes, for compound lvalues we need to recurse because forming x.y doesn't
immediately read x. And looking through COND/COMPOUND matches
"potential results" of an expression
https://eel.is/c++draft/basic#def.odr-3
Hmm, including INDIRECT_REF and FLOAT_EXPR seems wrong, though.
For more complex trees the expectation is that mark_exp_read will
be called when creating or folding those trees (like CALL_EXPR etc.).
Admittedly it isn't very clean but mostly happens to work fine for years.
diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc
index 9a98628d9e8..addbc29d104 100644
--- a/gcc/cp/cp-gimplify.cc
+++ b/gcc/cp/cp-gimplify.cc
@@ -3221,16 +3221,8 @@ cp_fold (tree x, fold_flags_t flags)
clear_decl_read = false;
if (code == MODIFY_EXPR
&& (VAR_P (op0) || TREE_CODE (op0) == PARM_DECL)
- && !DECL_READ_P (op0)
- && (VAR_P (op0) ? warn_unused_but_set_variable
- : warn_unused_but_set_parameter) > 2
- && BINARY_CLASS_P (TREE_OPERAND (x, 1))
- && TREE_OPERAND (TREE_OPERAND (x, 1), 0) == op0)
- {
- mark_exp_read (TREE_OPERAND (TREE_OPERAND (x, 1), 1));
Guess another option instead of mark_exp_read would be some
cp_walk_tree_without_duplicates that would return if it finds
any references to op0 in that subexpression.
But my simplifying patch didn't seem to break anything, so adding more
complexity also seems unnecessary.
Am I wrong that it doesn't break anything?
Well, I'm not sure it is actually an error. finish_unary_op_expr doesn't
use cp_fully_fold result as an operand of {PRE,POST}{INC,DEC}REMENT_EXPR
(that would be wrong, we don't want the operand to fold into non-lvalue), it
is called only to find out if overflow warning should be emitted.
But it only warns if the whole expression folds to a constant, which can
never happen for these tree codes. So folding the operand is useless.
Seems you're right, can tweak it to punt for those codes earlier instead.
In fact, I wonder if the finish_unary_op_expr function is ever called on
POST{IN,DE}CREMENT_EXPR.
They seem to go through finish_increment_expr instead.
Jason
