Bug 26600 - [4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
[4.1/4.2 Regression] internal compiler error: in push_reload, at reload.c:1303
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: target
4.1.1
: P1 normal
: 4.1.1
Assigned To: Roger Sayle
: ice-on-valid-code, ssemmx
Depends on: 26449
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-07 22:07 UTC by Florian Schanda
Modified: 2006-05-18 01:50 UTC (History)
4 users (show)

See Also:
Host: 32bits
Target: i686-pc-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-08 10:18:34


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Schanda 2006-03-07 22:07:34 UTC
void fdct_int32()
{
	int tmp4, tmp5, tmp7;
	int z1, z2, z3, z4, z5;
	int *dataptr;
	int i;
	
	for (i = 0; i < 8; i++) {
		tmp7 = dataptr[0];
		
		z3 = tmp4;
		z4 = tmp5 + tmp7;
		z5 = (z3 + z4) * ((int) 9633);
		
		z3 += z5;
		
		dataptr[56] = tmp4 + z1 + z3;
		dataptr[40] = tmp5 + z2 + z4;
		
		dataptr++;
	}
}

When compiling the above file with the following command line arguments:
gcc -c -O -march=pentium4 -ftree-vectorize foo.c

I get the following error:
foo.c: In function 'fdct_int32':
foo.c:22: internal compiler error: in push_reload, at reload.c:1303
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

I discovered this while trying to compile the xvid sources using silly CFLAGS by accident. The above file is a somewhat reduced testcase.
Comment 1 Andrew Pinski 2006-03-08 03:06:22 UTC
Hmm, this works in "4.1.1 20060304" on x86_64 with -m32.
Comment 2 Richard Biener 2006-03-08 10:18:34 UTC
For mainline, this is a dup of 26449.  For 4.1.0 I can reproduce this:

#1  0x08493eae in push_reload (in=0x4023a4b8, out=0x40241280, 
    inloc=0x40244a84, outloc=0x40229be0, class=NO_REGS, inmode=V4SImode, 
    outmode=TImode, strict_low=0, optional=0, opnum=0, type=RELOAD_OTHER)
    at /space/rguenther/src/svn/gcc-4_1-branch/gcc/reload.c:1302

  gcc_assert (class != NO_REGS
              || (optional != 0 && type == RELOAD_FOR_OUTPUT));

(gdb) call debug_rtx (in)
(const_vector:V4SI [
        (const_int 9633 [0x25a1])
        (const_int 9633 [0x25a1])
        (const_int 9633 [0x25a1])
        (const_int 9633 [0x25a1])
    ])
(gdb) call debug_rtx (out)
(reg:TI 23 xmm2)

this problem may be latent on the mainline (so I make it depend on 26449).
This is a regression in that we didn't ICE here for 4.0, but we didn't do any vectorization there either.

So, who's the reload expert for vector stuff ;)
Comment 3 Richard Biener 2006-03-08 10:40:55 UTC
(gdb) call debug_rtx(*outloc)
(subreg:TI (reg:V4SI 23 xmm2 [99]) 0)

(but of course it looks like NO_REGS doesn't make any sense for this reload)

(gdb) up
#2  0x0849b343 in find_reloads (insn=0x402401b8, replace=0, ind_levels=0, 
    live_known=1, reload_reg_p=0x87f5a00)
    at /space/rguenther/src/svn/gcc-4_1-branch/gcc/reload.c:3953
3953                operand_reloadnum[goal_alternative_matched[i]]
(gdb) call debug_rtx (insn)
(insn 58 57 59 2 (set (subreg:TI (reg:V4SI 23 xmm2 [99]) 0)
        (lshiftrt:TI (subreg:TI (reg:V4SI 96) 0)
            (const_int 32 [0x20]))) 711 {sse2_lshrti3} (nil)
    (nil))

and we call push_reload with in
(subreg:TI (const_vector:V4SI [
            (const_int 9633 [0x25a1])
            (const_int 9633 [0x25a1])
            (const_int 9633 [0x25a1])
            (const_int 9633 [0x25a1])
        ]) 0)

Looking at reload.c:1018 I don't feel like wanting to dig further ;)
Comment 4 Andrew Pinski 2006-03-08 12:39:52 UTC
So it looks like this is HWI bug really, if a target needs to support TImode in any shape or form, HWI should be set to 64bits no questions asked.
Comment 5 Volker Reichelt 2006-03-26 13:13:58 UTC
Shorter testcase (compile with "gcc -O -ftree-vectorize -msse2"):

====================================================
void foo(int *p, int N)
{
    int i;
    for (i=0; i<8; ++i, ++p)
    {
        int j = N+2*(N+p[0]), k = 2*N+p[0];
        p[0] = j+N;
        p[5] = j+k;
    }
}
====================================================
Comment 6 Paolo Bonzini 2006-04-18 14:07:17 UTC
pinskia: You're right in some sense but, shudder, this will make things sloooow.
Comment 7 Andrew Pinski 2006-04-18 16:15:38 UTC
(In reply to comment #6)
> pinskia: You're right in some sense but, shudder, this will make things
> sloooow.

No it will not.  I and others have sped up the HWI being 64bit case as PPC-darwin was 32bit until the 64 in 32 mode came around and had to change.  Please come back with real prove that GCC will slow down with the change instead of just saying it will because I have already speed it up at least twice.
Comment 8 roger 2006-05-11 17:22:15 UTC
Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00472.html
Comment 9 Steven Bosscher 2006-05-14 14:23:31 UTC
Please take bugs if you post patches for them, it makes it easier to search for bugs that nobody is looking at.
Comment 10 Roger Sayle 2006-05-16 04:17:11 UTC
Subject: Bug 26600

Author: sayle
Date: Tue May 16 04:16:00 2006
New Revision: 113818

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113818
Log:

	PR target/26600
	* config/i386/i386.c (legitimate_constant_p) <CONST_DOUBLE>: TImode
	integer constants other than zero are only legitimate on TARGET_64BIT.
	<CONST_VECTOR> Only zero vectors are legitimate.
	(ix86_cannot_force_const_mem): Integral and vector constants can
	always be put in the constant pool.

	* gcc.target/i386/pr26600.c: New test case.


Added:
    trunk/gcc/testsuite/gcc.target/i386/pr26600.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog

Comment 11 Roger Sayle 2006-05-17 01:12:09 UTC
Subject: Bug 26600

Author: sayle
Date: Wed May 17 01:11:59 2006
New Revision: 113839

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113839
Log:

	PR target/26600
	* config/i386/i386.c (legitimate_constant_p) <CONST_DOUBLE>: TImode
	integer constants other than zero are only legitimate on TARGET_64BIT.
	<CONST_VECTOR> Only zero vectors are legitimate.
	(ix86_cannot_force_const_mem): Integral and vector constants can
	always be put in the constant pool.

	* gcc.target/i386/pr26600.c: New test case.


Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.target/i386/pr26600.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/config/i386/i386.c
    branches/gcc-4_1-branch/gcc/testsuite/ChangeLog

Comment 12 roger 2006-05-18 01:50:11 UTC
This is now fixed on both mainline and the 4.1 branch.