public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/57904] [4.9 Regression] Bogus(?) "invokes undefined behavior" warning with Fortran's finalization wrapper (gfortran.dg/class_48.f90) Date: Fri, 20 Dec 2013 06:26:00 -0000 [thread overview] Message-ID: <bug-57904-4-YrtKPOLGMU@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-57904-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57904 --- Comment #10 from Jeffrey A. Law <law at redhat dot com> --- Bernd, It's certainly good if the test outside the loop and inside the loop is the same. It's a lot more likely to be discovered to be redundant earlier. I have no idea how it would affect ivopts. Regardless of what the front-end presents us with, the early optimizers are just doing a crappy job here. If you look at the IL dump and propagate/simplify based on ubound_3 = 0 you'll find that a ton of code just goes away. The question in my mind is can we get the propagation/simplifications we want with a reasonable cost. We certainly have passes that will clean this up that we could schedule to run after copyprop, but an integrated solution may be significantly better from a compile-time standpoint. It also helps that we already have code which does, probably 95% of what we need in phi-only cprop. I suspect if we just marked things that obviously simplified down to copies/constants and re-used the phi-only-cprop code that everything would "just work" with a minimal compile-time hit. I'm hoping to prototype that tomorrow.
next prev parent reply other threads:[~2013-12-20 6:26 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-16 9:05 [Bug fortran/57904] New: " burnus at gcc dot gnu.org 2013-07-23 19:53 ` [Bug fortran/57904] " jamborm at gcc dot gnu.org 2013-08-09 12:53 ` ro at gcc dot gnu.org 2013-08-19 23:03 ` [Bug fortran/57904] [4.9 Regression] " hp at gcc dot gnu.org 2013-08-20 17:40 ` bernd.edlinger at hotmail dot de 2013-10-30 13:13 ` [Bug middle-end/57904] " rguenth at gcc dot gnu.org 2013-11-27 15:55 ` jakub at gcc dot gnu.org 2013-11-27 15:59 ` Joost.VandeVondele at mat dot ethz.ch 2013-12-19 21:32 ` law at redhat dot com 2013-12-20 5:51 ` bernd.edlinger at hotmail dot de 2013-12-20 6:26 ` law at redhat dot com [this message] 2013-12-20 7:21 ` dominiq at lps dot ens.fr 2013-12-20 8:36 ` jakub at gcc dot gnu.org 2013-12-20 9:54 ` bernd.edlinger at hotmail dot de 2013-12-20 19:22 ` law at redhat dot com 2013-12-20 21:56 ` dominiq at lps dot ens.fr 2013-12-20 21:58 ` dominiq at lps dot ens.fr 2013-12-20 22:27 ` law at redhat dot com 2013-12-20 22:28 ` law at redhat dot com 2014-01-17 17:50 ` law at gcc dot gnu.org 2014-01-17 17:51 ` law at redhat dot com
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-57904-4-YrtKPOLGMU@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).