* Re: [PATCH] Avoid some -Wunreachable-code-ctrl
[not found] <q2839s9-o1s-s07s-8orp-47244q7o0o8@fhfr.qr>
@ 2021-11-30 13:00 ` Mikael Morin
2021-11-30 13:25 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Mikael Morin @ 2021-11-30 13:00 UTC (permalink / raw)
To: Richard Biener, gcc-patches; +Cc: gfortran
Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
> diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> index f5ba7cecd54..16ee2afc9c0 100644
> --- a/gcc/fortran/frontend-passes.c
> +++ b/gcc/fortran/frontend-passes.c
> @@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr **e, walk_expr_fn_t exprfn, void *data)
> case EXPR_OP:
> WALK_SUBEXPR ((*e)->value.op.op1);
> WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
> - break;
> case EXPR_FUNCTION:
> for (a = (*e)->value.function.actual; a; a = a->next)
> WALK_SUBEXPR (a->expr);
I’m uncomfortable with the above change.
It makes it look like there is a fall through, but there is not.
Maybe inline the macro to make the continue explicit, or use
WALK_SUBEXPR instead of WALK_SUBEXPR_TAIL and hope the compiler will do
the tail call optimization.
Mikael
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Avoid some -Wunreachable-code-ctrl
2021-11-30 13:00 ` [PATCH] Avoid some -Wunreachable-code-ctrl Mikael Morin
@ 2021-11-30 13:25 ` Richard Biener
2021-11-30 14:18 ` Mikael Morin
0 siblings, 1 reply; 4+ messages in thread
From: Richard Biener @ 2021-11-30 13:25 UTC (permalink / raw)
To: Mikael Morin; +Cc: gcc-patches, gfortran
On Tue, 30 Nov 2021, Mikael Morin wrote:
> Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
> > diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> > index f5ba7cecd54..16ee2afc9c0 100644
> > --- a/gcc/fortran/frontend-passes.c
> > +++ b/gcc/fortran/frontend-passes.c
> > @@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr **e, walk_expr_fn_t exprfn,
> > void *data)
> > case EXPR_OP:
> > WALK_SUBEXPR ((*e)->value.op.op1);
> > WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
> > - break;
> > case EXPR_FUNCTION:
> > for (a = (*e)->value.function.actual; a; a = a->next)
> > WALK_SUBEXPR (a->expr);
>
> I’m uncomfortable with the above change.
> It makes it look like there is a fall through, but there is not.
> Maybe inline the macro to make the continue explicit, or use WALK_SUBEXPR
> instead of WALK_SUBEXPR_TAIL and hope the compiler will do the tail call
> optimization.
Ah, it follows the style in tree.c:walk_tree_1 where break was used
inconsistently after WALK_SUBTREE_TAIL which was then more obvious
to me to clean up. I didn't realize the fortran FE only had a
single WALK_SUBEXPR_TAIL.
I'm not sure inlining will make the situation more clear, for
sure using WALK_SUBEXPR would but it might loose the tailcall.
Would you accept an additional comment after WALK_SUBEXPR_TAIL like
case EXPR_OP:
WALK_SUBEXPR ((*e)->value.op.op1);
WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
/* tail-recurse */
? Btw, a fallthru would be diagnosed by GCC unless we put
/* Fallthru */
here. Maybe renaming WALK_SUBEXPR_TAIL to WALK_SUBEXPR_WITH_CONTINUE
or WALK_SUBEXPR_BY_TAIL_RECURSING or WALK_SUBEXPR_TAILRECURSE would
be more obvious?
Thanks,
Richard.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Avoid some -Wunreachable-code-ctrl
2021-11-30 13:25 ` Richard Biener
@ 2021-11-30 14:18 ` Mikael Morin
2021-11-30 14:27 ` Richard Biener
0 siblings, 1 reply; 4+ messages in thread
From: Mikael Morin @ 2021-11-30 14:18 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc-patches, gfortran
On 30/11/2021 14:25, Richard Biener wrote:
> On Tue, 30 Nov 2021, Mikael Morin wrote:
>
>> Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
>>> diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
>>> index f5ba7cecd54..16ee2afc9c0 100644
>>> --- a/gcc/fortran/frontend-passes.c
>>> +++ b/gcc/fortran/frontend-passes.c
>>> @@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr **e, walk_expr_fn_t exprfn,
>>> void *data)
>>> case EXPR_OP:
>>> WALK_SUBEXPR ((*e)->value.op.op1);
>>> WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
>>> - break;
>>> case EXPR_FUNCTION:
>>> for (a = (*e)->value.function.actual; a; a = a->next)
>>> WALK_SUBEXPR (a->expr);
>>
>> I’m uncomfortable with the above change.
>> It makes it look like there is a fall through, but there is not.
>> Maybe inline the macro to make the continue explicit, or use WALK_SUBEXPR
>> instead of WALK_SUBEXPR_TAIL and hope the compiler will do the tail call
>> optimization.
>
> Ah, it follows the style in tree.c:walk_tree_1 where break was used
> inconsistently after WALK_SUBTREE_TAIL which was then more obvious
> to me to clean up. I didn't realize the fortran FE only had a
> single WALK_SUBEXPR_TAIL.
>
> I'm not sure inlining will make the situation more clear, for
> sure using WALK_SUBEXPR would but it might loose the tailcall.
>
> Would you accept an additional comment after WALK_SUBEXPR_TAIL like
>
> case EXPR_OP:
> WALK_SUBEXPR ((*e)->value.op.op1);
> WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
> /* tail-recurse */
>
My preference would be a gcc_unreachable() or something similar, but I
understand it would get a warning as well?
Without better idea, I’m fine with an even more explicit comment:
/* No fallthru because of the tail recursion above. */
> ? Btw, a fallthru would be diagnosed by GCC unless we put
>
> /* Fallthru */
>
> here.
Sure, but my main concern was misreading from programmers (including
me), which is not diagnosed by compilers.
> Maybe renaming WALK_SUBEXPR_TAIL to WALK_SUBEXPR_WITH_CONTINUE
> or WALK_SUBEXPR_BY_TAIL_RECURSING or WALK_SUBEXPR_TAILRECURSE would
> be more obvious?
>
I think the comment above would be enough.
Thanks.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] Avoid some -Wunreachable-code-ctrl
2021-11-30 14:18 ` Mikael Morin
@ 2021-11-30 14:27 ` Richard Biener
0 siblings, 0 replies; 4+ messages in thread
From: Richard Biener @ 2021-11-30 14:27 UTC (permalink / raw)
To: Mikael Morin; +Cc: gcc-patches, gfortran
On Tue, 30 Nov 2021, Mikael Morin wrote:
> On 30/11/2021 14:25, Richard Biener wrote:
> > On Tue, 30 Nov 2021, Mikael Morin wrote:
> >
> >> Le 29/11/2021 ? 16:03, Richard Biener via Gcc-patches a ?crit :
> >>> diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
> >>> index f5ba7cecd54..16ee2afc9c0 100644
> >>> --- a/gcc/fortran/frontend-passes.c
> >>> +++ b/gcc/fortran/frontend-passes.c
> >>> @@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr **e, walk_expr_fn_t
> >>> exprfn,
> >>> void *data)
> >>> case EXPR_OP:
> >>> WALK_SUBEXPR ((*e)->value.op.op1);
> >>> WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
> >>> - break;
> >>> case EXPR_FUNCTION:
> >>> for (a = (*e)->value.function.actual; a; a = a->next)
> >>> WALK_SUBEXPR (a->expr);
> >>
> >> I?m uncomfortable with the above change.
> >> It makes it look like there is a fall through, but there is not.
> >> Maybe inline the macro to make the continue explicit, or use WALK_SUBEXPR
> >> instead of WALK_SUBEXPR_TAIL and hope the compiler will do the tail call
> >> optimization.
> >
> > Ah, it follows the style in tree.c:walk_tree_1 where break was used
> > inconsistently after WALK_SUBTREE_TAIL which was then more obvious
> > to me to clean up. I didn't realize the fortran FE only had a
> > single WALK_SUBEXPR_TAIL.
> >
> > I'm not sure inlining will make the situation more clear, for
> > sure using WALK_SUBEXPR would but it might loose the tailcall.
> >
> > Would you accept an additional comment after WALK_SUBEXPR_TAIL like
> >
> > case EXPR_OP:
> > WALK_SUBEXPR ((*e)->value.op.op1);
> > WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
> > /* tail-recurse */
> >
> My preference would be a gcc_unreachable() or something similar, but I
> understand it would get a warning as well?
>
> Without better idea, I?m fine with an even more explicit comment:
>
> /* No fallthru because of the tail recursion above. */
>
> > ? Btw, a fallthru would be diagnosed by GCC unless we put
> >
> > /* Fallthru */
> >
> > here.
> Sure, but my main concern was misreading from programmers (including me),
> which is not diagnosed by compilers.
>
> > Maybe renaming WALK_SUBEXPR_TAIL to WALK_SUBEXPR_WITH_CONTINUE
> > or WALK_SUBEXPR_BY_TAIL_RECURSING or WALK_SUBEXPR_TAILRECURSE would
> > be more obvious?
> >
> I think the comment above would be enough.
Installed as follows.
Richard.
From e5c2a436ef7596d254ffefd279742382b1ff546b Mon Sep 17 00:00:00 2001
From: Richard Biener <rguenther@suse.de>
Date: Tue, 30 Nov 2021 15:25:17 +0100
Subject: [PATCH] Add comment to indicate tail recursion
To: gcc-patches@gcc.gnu.org
My previous change removed an unreachable break; there (an
unreachable continue; would have been more to the point). The
following re-adds a comment explaining that WALK_SUBEXPR_TAIL
does not fall through but tail recurses.
2021-11-30 Richard Biener <rguenther@suse.de>
gcc/fortran/
* frontend-passes.c (gfc_expr_walker): Add comment to
indicate tail recursion.
---
gcc/fortran/frontend-passes.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index 16ee2afc9c0..4764c834f4f 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -5229,6 +5229,7 @@ gfc_expr_walker (gfc_expr **e, walk_expr_fn_t exprfn, void *data)
case EXPR_OP:
WALK_SUBEXPR ((*e)->value.op.op1);
WALK_SUBEXPR_TAIL ((*e)->value.op.op2);
+ /* No fallthru because of the tail recursion above. */
case EXPR_FUNCTION:
for (a = (*e)->value.function.actual; a; a = a->next)
WALK_SUBEXPR (a->expr);
--
2.31.1
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-11-30 14:27 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <q2839s9-o1s-s07s-8orp-47244q7o0o8@fhfr.qr>
2021-11-30 13:00 ` [PATCH] Avoid some -Wunreachable-code-ctrl Mikael Morin
2021-11-30 13:25 ` Richard Biener
2021-11-30 14:18 ` Mikael Morin
2021-11-30 14:27 ` Richard Biener
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).