> 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?
(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.
