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.


             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: 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).