On Thu, May 2, 2024 at 11:40 PM Andrew Pinski <quic_apin...@quicinc.com> wrote:
>
> When we have :
> `void f (int y, int z) { int x = ( z++,y); }`
>
> This would have printed the decl's initializer without
> parentheses which can confusion if you think that is defining
> another variable rather than the compound expression.
>
> This adds parenthese around DECL_INIT if it was a COMPOUND_EXPR.
Looking it seems we'd hit a similar issue for
foo ((z++,y), 2);
thus in CALL_EXPR context. Also
int k;
void foo (int i, int j)
{
k = (i, 2) + j;
}
dumps as
{
k = i, j + 2;;
}
(ok that's folded to (i, j + 2) but still).
So shouldn't we bite the bullet and wrap all COMPOUND_EXPRs in
parens instead? Possibly "tail-calling" the case of
a, b, c in COMPOUND_EXPR dumping itself?
Thanks,
Richard.
> Bootstrapped and tested on x86_64-linux-gnu.
>
> gcc/ChangeLog:
>
> * tree-pretty-print.cc (print_declaration): Add parenthese
> around DECL_INIT if it was a COMPOUND_EXPR.
>
> Signed-off-by: Andrew Pinski <quic_apin...@quicinc.com>
> ---
> gcc/tree-pretty-print.cc | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/tree-pretty-print.cc b/gcc/tree-pretty-print.cc
> index 825ba74443b..8b766dcd2b8 100644
> --- a/gcc/tree-pretty-print.cc
> +++ b/gcc/tree-pretty-print.cc
> @@ -4240,7 +4240,14 @@ print_declaration (pretty_printer *pp, tree t, int
> spc, dump_flags_t flags, bool
> pp_equal (pp);
> pp_space (pp);
> if (!(flags & TDF_SLIM))
> - dump_generic_node (pp, DECL_INITIAL (t), spc, flags, false);
> + {
> + bool need_paren = TREE_CODE (DECL_INITIAL (t)) == COMPOUND_EXPR;
> + if (need_paren)
> + pp_left_paren (pp);
> + dump_generic_node (pp, DECL_INITIAL (t), spc, flags, false);
> + if (need_paren)
> + pp_right_paren (pp);
> + }
> else
> pp_string (pp, "<<< omitted >>>");
> }
> --
> 2.43.0
>
