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.
