public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/50904] Induct benchmark of polyhedron slows down when -fno-protect-parens is enabled by -Ofast.
Date: Fri, 28 Oct 2011 19:14:00 -0000 [thread overview]
Message-ID: <bug-50904-4-VJP84LxEXU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-50904-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50904
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-10-28
CC| |burnus@net-b.de
Ever Confirmed|0 |1
--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-10-28 19:14:18 UTC ---
On a Core2Duo the run time when induct is compiled with -Ofast is 14.76s, when
it is compiled with -fprotect-parens -Ofast, the run time is 14.29.
> Please provide your suggestions.
As discussed with Tobias Burnus, I think the inclusion of -fno-protect-parens
in -Ofast was a poor choice. I'ld like to see it reverted, not on the ground of
speed, but because it violates one of the basic requirement of the Fortran
standard (BTW it breaks two of my codes).
next prev parent reply other threads:[~2011-10-28 19:14 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-28 17:19 [Bug rtl-optimization/50904] New: " venkataramanan.kumar.gnu at gmail dot com
2011-10-28 19:14 ` dominiq at lps dot ens.fr [this message]
2011-10-30 9:41 ` [Bug rtl-optimization/50904] " rguenth at gcc dot gnu.org
2011-10-30 9:41 ` rguenth at gcc dot gnu.org
2011-10-30 11:25 ` dominiq at lps dot ens.fr
2011-10-30 11:35 ` dominiq at lps dot ens.fr
2011-11-01 13:53 ` ebotcazou at gcc dot gnu.org
2011-11-02 5:51 ` venkataramanan.kumar.gnu at gmail dot com
2011-11-04 21:55 ` ebotcazou at gcc dot gnu.org
2011-11-05 11:54 ` [Bug rtl-optimization/50904] [4.7 regression] pessimization " rguenth at gcc dot gnu.org
2011-11-07 0:33 ` ebotcazou at gcc dot gnu.org
2011-11-08 0:43 ` ebotcazou at gcc dot gnu.org
2011-11-09 9:03 ` ebotcazou at gcc dot gnu.org
2011-11-09 10:40 ` venkataramanan.kumar.gnu at gmail dot com
2011-11-11 23:04 ` venkataramanan.kumar.gnu at gmail dot com
2011-11-12 17:22 ` [Bug tree-optimization/50904] " ebotcazou at gcc dot gnu.org
2011-11-19 7:18 ` venkataramanan.kumar.gnu at gmail dot com
2011-11-19 9:09 ` ebotcazou at gcc dot gnu.org
2011-12-01 8:51 ` rguenther at suse dot de
2011-12-01 19:53 ` [Bug rtl-optimization/50904] " ebotcazou at gcc dot gnu.org
2011-12-02 9:49 ` rguenther at suse dot de
2011-12-02 10:56 ` ebotcazou at gcc dot gnu.org
2011-12-02 11:51 ` rguenth at gcc dot gnu.org
2011-12-02 14:04 ` burnus at gcc dot gnu.org
2011-12-02 14:32 ` rguenther at suse dot de
2011-12-02 14:41 ` burnus at gcc dot gnu.org
2011-12-02 15:04 ` rguenther at suse dot de
2011-12-02 16:03 ` burnus at gcc dot gnu.org
2011-12-02 16:13 ` howarth at nitro dot med.uc.edu
2011-12-02 16:15 ` rguenther at suse dot de
2011-12-02 16:30 ` burnus at gcc dot gnu.org
2011-12-02 16:33 ` rguenther at suse dot de
2011-12-02 16:38 ` dominiq at lps dot ens.fr
2011-12-02 16:47 ` dominiq at lps dot ens.fr
2011-12-02 17:07 ` burnus at gcc dot gnu.org
2011-12-02 21:21 ` ebotcazou at gcc dot gnu.org
2011-12-03 14:55 ` dominiq at lps dot ens.fr
2011-12-05 8:19 ` rguenther at suse dot de
2011-12-05 8:27 ` rguenther at suse dot de
2011-12-05 9:21 ` ebotcazou at gcc dot gnu.org
2011-12-05 9:57 ` rguenther at suse dot de
2011-12-05 10:13 ` dominiq at lps dot ens.fr
2011-12-05 10:21 ` rguenth at gcc dot gnu.org
2011-12-05 10:28 ` [Bug tree-optimization/50904] " ebotcazou at gcc dot gnu.org
2011-12-05 11:13 ` rguenth at gcc dot gnu.org
2011-12-05 14:38 ` rguenth at gcc dot gnu.org
2011-12-05 14:40 ` rguenth at gcc dot gnu.org
2011-12-05 17:30 ` ebotcazou at gcc dot gnu.org
2011-12-05 17:59 ` dominiq at lps dot ens.fr
2011-12-06 10:00 ` venkataramanan.kumar.gnu at gmail dot com
2011-12-07 13:21 ` venkataramanan.kumar.gnu at gmail 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-50904-4-VJP84LxEXU@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: link
Be 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).