Bug 38621 - [4.6/4.7/4.8 Regression] sh gcc unable to spill register when building ghostscript-gpl with -O2
Summary: [4.6/4.7/4.8 Regression] sh gcc unable to spill register when building ghosts...
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.3.2
: P4 normal
Target Milestone: 4.6.4
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 38793 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-24 14:57 UTC by Mike Frysinger
Modified: 2012-07-18 18:57 UTC (History)
6 users (show)

See Also:
Host:
Target: sh4-linux-gnu
Build:
Known to work: 4.1.2, 4.2.0, 4.6.4, 4.7.2
Known to fail: 4.3.2, 4.4.0
Last reconfirmed: 2008-12-25 03:38:20


Attachments
gdevifno.i (415 bytes, text/plain)
2008-12-24 14:59 UTC, Mike Frysinger
Details
gdevifno.orig.i (30.83 KB, text/plain)
2008-12-24 15:02 UTC, Mike Frysinger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2008-12-24 14:57:41 UTC
when building ghostscript-gpl-8.63, gcc-4.3.2 fails:

sh4-unknown-linux-gnu-gcc  -DHAVE_MKSTEMP -DHAVE_HYPOT -DHAVE_FILE64 -DHAVE_MKSTEMP64 -DHAVE_FONTCONFIG -O2 -Wall -Wstrict-prototypes -Wundef -Wmissing-declarations -Wmissing-prototypes -Wwrite-strings -Wno-strict-aliasing -fno-builtin -fno-common -DHAVE_STDINT_H -DGX_COLOR_INDEX_TYPE="unsigned long long" -O2 -m4 -pipe -DGS_DEVS_SHARED -DGS_DEVS_SHARED_DIR=\"/usr/lib/ghostscript/8.63\" -I./obj -I./src  -o ./obj/gdevifno.o -c ./src/gdevifno.c
./src/gdevifno.c:195: warning: no previous prototype for ‘init_p9color’
./src/gdevifno.c:56: warning: ‘cmap2rgb’ declared ‘static’ but never defined
./src/gdevifno.c: In function ‘inferno_rgb2cmap’:
./src/gdevifno.c:150: error: unable to find a register to spill in class ‘R0_REGS’
./src/gdevifno.c:150: error: this is the insn:
(insn:HI 132 192 154 17 ./src/gdevifno.c:148 (set (mem/s:SI (plus:SI (reg/v/f:SI 8 r8 [orig:183 dev ] [183])
                (reg/f:SI 2 r2 [225])) [3 S4 A32])
        (reg:SI 3 r3 [227])) 172 {movsi_ie} (expr_list:REG_DEAD (reg:SI 3 r3 [227])
        (expr_list:REG_DEAD (reg/f:SI 2 r2 [225])
            (expr_list:REG_DEAD (reg/v/f:SI 8 r8 [orig:183 dev ] [183])
                (expr_list:REG_EQUAL (const_int 1 [0x1])
                    (nil))))))
./src/gdevifno.c:150: confused by earlier errors, bailing out
make: *** [obj/gdevifno.o] Error 1
Comment 1 Mike Frysinger 2008-12-24 14:59:03 UTC
Created attachment 16980 [details]
gdevifno.i

$ sh4-unknown-linux-gnu-gcc -c gdevifno.i -O2
gdevifno.i: In function ‘inferno_rgb2cmap’:
gdevifno.i:41: error: unable to find a register to spill in class ‘R0_REGS’
gdevifno.i:41: error: this is the insn:
(insn:HI 19 61 46 2 gdevifno.i:39 (set (mem/s:SI (plus:SI (reg/v/f:SI 4 r4 [orig:161 bdev ] [161])
                (reg/f:SI 1 r1 [167])) [3 S4 A32])
        (reg:SI 2 r2 [169])) 172 {movsi_ie} (expr_list:REG_DEAD (reg:SI 2 r2 [169])
        (expr_list:REG_DEAD (reg/f:SI 1 r1 [167])
            (expr_list:REG_DEAD (reg/v/f:SI 4 r4 [orig:161 bdev ] [161])
                (expr_list:REG_EQUAL (const_int 1 [0x1])
                    (nil))))))
gdevifno.i:41: confused by earlier errors, bailing out
Comment 2 Mike Frysinger 2008-12-24 15:02:33 UTC
Created attachment 16981 [details]
gdevifno.orig.i

here's the original file in case the reduced test case is troublesome
Comment 3 Kazumoto Kojima 2008-12-25 03:38:20 UTC
Here is an another reduced testcase.

struct s
{
  char a[512];
  int b;
  int c;
};

long long
foo (struct s *p, int m, int r)
{
  if (r == m)
    p->b = 3;
  p->c = 1;
  return m;
}

I've confirmed that this fails with the trunk compiler too.

The insn scheduling before reload permutes the insns of
the exit basic block like as:

;;   ======================================================
;;   -- basic block 5 from 18 to 38 -- before reload
;;   ======================================================

;;	  0-->    18 r166=0x204                        :(issue+load_store),nothing,memory
changing bb of uid 55
;;	  0-->    55 {r170=r161<<0x1;t=r161<0x0;}      :issue,int
changing bb of uid 56
;;	  1-->    56 r170=-t                           :issue,int
changing bb of uid 46
;;	  1-->    46 r0=r161                           :issue
;;	  2-->    19 r168=0x1                          :issue,int
changing bb of uid 47
;;	  2-->    47 r1=r170                           :issue
;;	  3-->    20 [r160+r166]=r168                  :(issue+load_store),nothing,memory
;;	  3-->    38 use r0                            :nothing

i.e. insn 46 r0=r161 is placed before insn 20.
Unfortunately insn 20 [r160+r166]=r168 requires r0 because
sh has r0 + reg addressing only.  -fno-schedule-insns gets
rid of the error, though I have no idea for the right solution
ATM.
Comment 4 Kazumoto Kojima 2009-01-11 01:29:03 UTC
*** Bug 38793 has been marked as a duplicate of this bug. ***
Comment 5 Richard Biener 2009-01-24 10:21:05 UTC
GCC 4.3.3 is being released, adjusting target milestone.
Comment 6 Richard Biener 2009-08-04 12:29:40 UTC
GCC 4.3.4 is being released, adjusting target milestone.
Comment 7 Richard Biener 2010-05-22 18:13:01 UTC
GCC 4.3.5 is being released, adjusting target milestone.
Comment 8 Richard Biener 2011-06-27 12:13:27 UTC
4.3 branch is being closed, moving to 4.4.7 target.
Comment 9 Jakub Jelinek 2012-03-13 12:46:22 UTC
4.4 branch is being closed, moving to 4.5.4 target.
Comment 10 Oleg Endo 2012-07-16 22:24:11 UTC
I've tried to reproduce the issue with rev 189549 (GCC 4.8),
GCC 4.7.2 20120711 (prerelease) and GCC 4.6.4 20120716 (prerelease).
It seems this is no longer an issue.
Comment 11 Kazumoto Kojima 2012-07-18 01:11:47 UTC
(In reply to comment #10)
> I've tried to reproduce the issue with rev 189549 (GCC 4.8),
> GCC 4.7.2 20120711 (prerelease) and GCC 4.6.4 20120716 (prerelease).
> It seems this is no longer an issue.

4.6 and 4.7 are failing with -fschedule-insns for me.  We changed
the default behavior so that -fno-schedule-insns is default.
4.8 doesn't fail even with -fschedule-insns.  I guess that your
patches for index addressing fix it on trunk.  Perhaps we can
close this PR because it's fixed on trunk and looks no hope to fix
it for 4.6 and 4.7 compilers with -fschedule-insns.
Comment 12 Oleg Endo 2012-07-18 07:57:07 UTC
Author: olegendo
Date: Wed Jul 18 07:56:57 2012
New Revision: 189605

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189605
Log:
	PR target/38621
	* gcc.c-torture/compile/pr38621.c: New.


Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr38621.c
Modified:
    trunk/gcc/testsuite/ChangeLog
Comment 13 Oleg Endo 2012-07-18 18:57:38 UTC
(In reply to comment #11)
> (In reply to comment #10)
> > I've tried to reproduce the issue with rev 189549 (GCC 4.8),
> > GCC 4.7.2 20120711 (prerelease) and GCC 4.6.4 20120716 (prerelease).
> > It seems this is no longer an issue.
> 
> 4.6 and 4.7 are failing with -fschedule-insns for me.  We changed
> the default behavior so that -fno-schedule-insns is default.
> 4.8 doesn't fail even with -fschedule-insns.  I guess that your
> patches for index addressing fix it on trunk.  Perhaps we can
> close this PR because it's fixed on trunk and looks no hope to fix
> it for 4.6 and 4.7 compilers with -fschedule-insns.

OK.  I think it's better to take any -fschedule-insns follow ups to PR 22553.