public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "manu at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/36254] wrong "control reaches end of non-void function" warning Date: Mon, 27 Oct 2008 14:36:00 -0000 [thread overview] Message-ID: <20081027143506.23499.qmail@sourceware.org> (raw) In-Reply-To: <bug-36254-7667@http.gcc.gnu.org/bugzilla/> ------- Comment #11 from manu at gcc dot gnu dot org 2008-10-27 14:35 ------- (In reply to comment #10) > Language specific tree codes are allowed until the gimplification is done, > the cp_gimplify_expr langhook takes care of either rewriting the lang specific > tree code into GENERIC (COND_EXPR in this case), or tuplifying it right away. If they are permitted, they should be handled. If they are not handled, we should fail to compile or crash. Currently we just ignore them, which works ok for C since generic is basically C but fails for everything else. > BTW, looking at the other testcase, block_may_fallthru certainly isn't able > to say whether a SWITCH_EXPR can fall thru or not, and it wouldn't be actually > very easy. So perhaps we either need to run some pass that kills obvious dead > code before reporting the "control reaches end" warnings, or really try harder > during gimplification to figure out these cases and optimize it at that point. So basically you propose to do optimizations at -O0. I still do not understand what is the problem with setting no_warning. This is *really* compiler-generated code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36254
next prev parent reply other threads:[~2008-10-27 14:36 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2008-05-17 9:54 [Bug c++/36254] New: " pluto at agmk dot net 2008-05-17 9:55 ` [Bug c++/36254] " pluto at agmk dot net 2008-05-17 9:55 ` pluto at agmk dot net 2008-05-17 11:14 ` pluto at agmk dot net 2008-05-17 12:56 ` rguenth at gcc dot gnu dot org 2008-05-25 19:21 ` pluto at agmk dot net 2008-08-25 11:17 ` manu at gcc dot gnu dot org 2008-10-22 18:21 ` manu at gcc dot gnu dot org 2008-10-27 12:24 ` jakub at gcc dot gnu dot org 2008-10-27 12:43 ` manu at gcc dot gnu dot org 2008-10-27 14:06 ` jakub at gcc dot gnu dot org 2008-10-27 14:36 ` manu at gcc dot gnu dot org [this message] 2008-12-28 3:32 ` pinskia at gcc dot gnu dot org 2008-12-28 3:36 ` [Bug c++/36254] [4.2/4.3/4.4 Regression] wrong "control reaches end of non-void function" warning with IF_STMT pinskia at gcc dot gnu dot org 2008-12-29 21:49 ` rguenth at gcc dot gnu dot org 2009-01-11 21:15 ` jakub at gcc dot gnu dot org 2009-01-11 21:33 ` [Bug c++/36254] [4.2/4.3 " jakub at gcc dot gnu dot org 2009-02-14 10:05 ` pinskia at gcc dot gnu dot org 2009-03-31 20:51 ` [Bug c++/36254] [4.3 " jsm28 at gcc dot gnu dot org 2009-08-04 12:40 ` rguenth at gcc dot gnu dot org 2010-05-22 18:24 ` rguenth at gcc dot gnu dot org 2010-09-02 16:23 ` pluto at agmk dot net
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=20081027143506.23499.qmail@sourceware.org \ --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).