public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor Date: Wed, 12 Jan 2022 16:33:25 +0000 [thread overview] Message-ID: <bug-103991-4-PnIcuKqYWQ@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-103991-4@http.gcc.gnu.org/bugzilla/> 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?
next prev parent reply other threads:[~2022-01-12 16:33 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-12 13:56 [Bug c++/103991] New: " sbergman at redhat dot com 2022-01-12 14:03 ` [Bug c++/103991] [12 Regression] " jakub at gcc dot gnu.org 2022-01-12 16:04 ` jakub at gcc dot gnu.org 2022-01-12 16:06 ` jakub at gcc dot gnu.org 2022-01-12 16:33 ` jakub at gcc dot gnu.org [this message] 2022-01-12 16:47 ` jakub at gcc dot gnu.org 2022-01-12 16:58 ` jakub at gcc dot gnu.org 2022-01-12 19:42 ` rguenther at suse dot de 2022-01-12 20:02 ` jakub at gcc dot gnu.org 2022-01-14 11:10 ` cvs-commit at gcc dot gnu.org 2022-01-17 17:48 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-103991-4-PnIcuKqYWQ@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).