https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116775

--- Comment #10 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> Indeed, unevaluated for __builtin_constant_p is not unevaluated in the C++
> standard sense, just the behavior that we normally just fold the routine to
> false if TREE_SIDE_EFFECTS on the operands early.  Except for coros it isn't
> a big deal, it is ok just fold the builtin to 0.
> As I wrote, one option is when the coro lowering sees __builtin_constant_p
> look for co_await etc. in the argument and if it is there, fold the builtin
> manually to 0 instead of handling those and thus pretend co_* wasn't there
> at all.
> Or if we see those in __builtin_constant_p (exp), rewrite it into
> __builtin_constant_p (0 && exp) where we'd somehow force TREE_SIDE_EFFECTS.
> Note, __builtin_constant_p isn't the only problem, [[assume (exp)]]; is as
> well,
> __builtin_has_attribute I think too, maybe __builtin_choose_expr.

ack .. so then we do need to handle it manually - probably in the initial
co_await walk - we will also need to consider the other cases;

I've just made a patch for the unevaluated context cases (typeid, sizeof,
decltype) which seems OK - apart from the fact that we did not mark typeid
expressions as unevaluated - so will have to see if there's fallout from that.

Reply via email to