From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10142 invoked by alias); 1 Nov 2013 20:06:32 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10112 invoked by uid 48); 1 Nov 2013 20:06:28 -0000 From: "meissner at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: meissner at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-11/txt/msg00066.txt.bz2 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 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: . Find the GDB manual and other documentation resources online at: . 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") 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.