public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "meissner at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/58968] New: Powerpc -mlra cannot compile ormas1.f in gamess Spec 2006 with -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops Date: Fri, 01 Nov 2013 20:06:00 -0000 [thread overview] Message-ID: <bug-58968-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58968 Bug ID: 58968 Summary: Powerpc -mlra cannot compile ormas1.f in gamess Spec 2006 with -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Created attachment 31139 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31139&action=edit Fortran source to show the problem The spec 2006 benchmark gamess cannot be compiled with GCC subversion id 204267, using the -m32 -mcpu=power7 -O3 -mlra -w -ffast-math -funroll-loops options (the -w is to silence some of the warnings due to the types not being the same, but it works perfectly without the -mlra option). Dropping either -mlra or -funroll-loops will allow the benchmark to be compiled. This may be the same underlying bug as PR 58967 since that also will not build if both loop unrolling and lra register allocation are specified. I'm submitting this as separate bug because the insn that it is dying on is different. Here is the traceback: -bns-> /opt/at7.0/bin/gdb f951 GNU gdb (GDB) 7.6.50.20130722-cvs Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "powerpc64-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word". .. Reading symbols from /home/meissner/fsf-build-ppc64/trunk-204267/gcc/f951...done. Breakpoint 1 at 0x10d24480: file /home/meissner/fsf-src/trunk-204267/gcc/diagnostic.c, line 1182. Breakpoint 2 at 0x10d25dd0: file /home/meissner/fsf-src/trunk-204267/gcc/diagnostic.c, line 1123. Breakpoint 3 at 0x10d9c3a0 Breakpoint 4 at 0x10d9c448 File tree.h will be skipped when stepping. Successfully loaded GDB hooks for GCC (gdb) r -mcpu=power7 -quiet -O3 -mlra -w -ffast-math -funroll-loops -m32 ormas1.fppized.f Starting program: /home/meissner/fsf-build-ppc64/trunk-204267/gcc/f951 -mcpu=power7 -quiet -O3 -mlra -w -ffast-math -funroll-loops -m32 ormas1.fppized.f Breakpoint 1, fancy_abort (file=0x10dfb400 "/home/meissner/fsf-src/trunk-204267/gcc/lra.c", line=2034, function=0x10dfb1b8 <check_rtl(bool)::__FUNCTION__> "check_rtl") at /home/meissner/fsf-src/trunk-204267/gcc/diagnostic.c:1182 1182 { (gdb) up #1 0x000000001059fb80 in check_rtl (final_p=final_p@entry=true) at /home/meissner/fsf-src/trunk-204267/gcc/lra.c:2034 2034 lra_assert (constrain_operands (1)); (gdb) print insn $1 = (rtx) 0xfffabc0d338 (gdb) pr warning: Expression is not an assignment (and might have no effect) (insn 19319 19318 19320 1557 (set (reg:CC 66 ctr [4379]) (reg:CC 66 ctr [4379])) 439 {*movcc_internal1} (nil)) (gdb) In the past when I was looking at the code, we could paper over the problem by adding a constraint in movcc_internal1 that allowed moving the CTR register to itself. However, LRA should not be generating a move to the same register (which will eventually be deleted). An alternative method is constrain CC to not go in the CTR register. I did this at one point, but it did have some performance impacts, so I never submitted the code.
next reply other threads:[~2013-11-01 20:06 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-11-01 20:06 meissner at gcc dot gnu.org [this message] 2013-11-02 23:48 ` [Bug rtl-optimization/58968] " steven at gcc dot gnu.org 2013-11-02 23:49 ` steven at gcc dot gnu.org 2013-11-04 16:14 ` vmakarov at gcc dot gnu.org 2013-11-04 16:21 ` vmakarov at gcc dot gnu.org 2014-09-19 13:30 ` dominiq at lps dot ens.fr 2014-09-22 19:43 ` meissner at gcc dot gnu.org 2014-09-22 19:45 ` meissner at gcc dot gnu.org 2014-09-22 21:14 ` meissner 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-58968-4@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).