https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103991
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For IF_STMT_CONSTEXPR_P and IF_STMT_CONSTEVAL_P IF_STMTs, it is unclear what we
should do, because in either case we throw away the other branch if any.
Either we do for those what we used to do before r12-5638 and risk
-Wunreachable-code warnings (when/if it is readded), e.g. on code like:
if constexpr (true)
return 0;
some code;
but we don't emit these -Wreturn-type false positives in cases where the
untaken block of code doesn't fall through.
Or the r12-5638 can result in such false positives.
Or perhaps we should track if we had the other block of code at all (if not, it
is ok to do what we do right now) and if possible otherwise try to figure out
if the other block could fall through and if it can't, perhaps replace the
void_node with __builtin_unreachable () call?
For IF_STMT_CONSTEVAL_P we still have the other branch around and could perhaps
call block_may_fallthru on it, but for IF_STMT_CONSTEXPR_P we discard it
earlier,
outside of templates already during parsing.
Now, as Richi's warning isn't in GCC 12, quickest/safest temporary fix would be
to revert to previous behavior for IF_STMT_CONSTEXPR_P and IF_STMT_CONSTEVAL_P,
if (IF_STMT_CONSTEVAL_P (stmt))
stmt = else_;
else if (IF_STMT_CONSTEXPR_P (stmt))
stmt = integer_nonzerop (cond) ? then_ ? else_;
else
stmt = build3 (COND_EXPR, void_type_node, cond, then_, else_);
Jason, thoughts on this?
