https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775
--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #4) > So, e.g. co_await_find_in_subtree/await_statement_expander/find_any_await > and maybe other coroutines.cc cp_walk_tree callbacks could use some helper > for CALL_EXPR and in that case if it is a BUILT_IN_CONSTANT_P call and the > argument has TREE_SIDE_EFFECTS, set *walk_subtrees = 0. that seems reasonable. (In reply to Jakub Jelinek from comment #5) > On the other side, perhaps completely ignoring CO_AWAIT_EXPR in there (dunno > about others) might not be correct either, I guess the function is supposed > to be still considered a coroutine. > So perhaps it needs to be treated more like 0 && co_await ... or if (false) > co_await ... or something similar. > Also note there are other functions which ignore their argument > side-effects, I think e.g. __builtin_classify_type does. > And wonder about [[assume (co_await ...)]]; A lot of these interactions are not spelled out (and were probably not really throught about much, I guess). I am not sure that an await_expression can be BUILT_IN_CONSTANT_P because its value is the output of awaiter.await_resume() - so that, even if awaiter.await_ready() is always true - there is still a function call to obtain the result. Having said that ... I wonder about constexpr on await_resume () [coroutines cannot be constexpr, but thay can contain constexpr].
