https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74762
--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to Manuel López-Ibáñez from comment #5) > (In reply to Patrick Palka from comment #1) > > Looks like warn_uninit() suppresses the warning on 'i' because the > > TREE_NO_WARNING flag is set on the ARRAY_REF by the C++ FE (in > > finish_parenthesized_expr(), for an unrelated purpose). > > I wonder if a quick work-around for this case in particular is to check for: > > if (TREE_CODE (expr) == MODIFY_EXPR) > > like the C parser does: > > /* A parenthesized expression. */ > location_t loc_open_paren = c_parser_peek_token (parser)->location; > c_parser_consume_token (parser); > expr = c_parser_expression (parser); > if (TREE_CODE (expr.value) == MODIFY_EXPR) > TREE_NO_WARNING (expr.value) = 1; > if (expr.original_code != C_MAYBE_CONST_EXPR) > expr.original_code = ERROR_MARK; > /* Don't change EXPR.ORIGINAL_TYPE. */ > location_t loc_close_paren = c_parser_peek_token (parser)->location; > set_c_expr_source_range (&expr, loc_open_paren, loc_close_paren); > c_parser_skip_until_found (parser, CPP_CLOSE_PAREN, > "expected %<)%>"); > > Then the bug will only trigger for code such as ((lhs=rhs)), which is what > TREE_NO_WARNING is trying to avoid warning for. Unfortunately it looks like the purpose of setting TREE_NO_WARNING in finish_parenthesized_expr() is not limited to assignments within conditionals, it's also important for the -Wparentheses warning about confusing precedence (e.g. warn for "a + b << c" but not for "a + (b << c)")
