On Wed, Mar 6, 2024 at 1:03 AM Iain Sandoe <i...@sandoe.co.uk> wrote:
>
>
>
> > On 5 Mar 2024, at 17:31, H.J. Lu <hjl.to...@gmail.com> wrote:
> >
> > On Sat, Jan 18, 2020 at 4:54 AM Iain Sandoe <i...@sandoe.co.uk> wrote:
> >>
>
> >> 2020-01-18 Iain Sandoe <i...@sandoe.co.uk>
> >>
> >> * Makefile.in: Add coroutine-passes.o.
> >> * builtin-types.def (BT_CONST_SIZE): New.
> >> (BT_FN_BOOL_PTR): New.
> >> (BT_FN_PTR_PTR_CONST_SIZE_BOOL): New.
> >> * builtins.def (DEF_COROUTINE_BUILTIN): New.
> >> * coroutine-builtins.def: New file.
> >> * coroutine-passes.cc: New file.
> >
> > There are
> >
> > tree res_tgt = TREE_OPERAND (gimple_call_arg (stmt, 2), 0);
> > tree &res_dest = destinations.get_or_insert (idx, &existed);
> > if (existed && dump_file)
> > Why does this behavior depend on dump_file?
>
> This was checking for a potential wrong-code error during development;
> there is no point in making it into a diagnostic (since the user could not fix
> the problem if it happened). I guess changing to a gcc_checking_assert()
> would be reasonable but I’d prefer to do that once GCC-15 opens.
>
> Have you found any instance where this results in a reported bug?
No, I haven't. I only noticed it by chance.
> (I do not recall anything on my coroutines bug list that would seem to
> indicate this).
>
> thanks for noting it.
> Iain
>
>
> > {
> > fprintf (
> > dump_file,
> > "duplicate YIELD RESUME point (" HOST_WIDE_INT_PRINT_DEC
> > ") ?\n",
> > idx);
> > print_gimple_stmt (dump_file, stmt, 0,
> > TDF_VOPS|TDF_MEMSYMS);
> > }
> > else
> > res_dest = res_tgt;
> >
> > H.J.
>
--
H.J.
