[Bug target/20813] New: ICE in gen_reg_rtx for 3 spec tests

[Bug target/20813] New: ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Current GCC mainline fails to build SPEC CPU2000 tests gzip, bzip2,
and mesa on powerpc64-linux with -m64.  The same ICE is seen with
test gcc.c-torture/execute/930106-1.c:
                                                                                
elm3b149% /home/janis/tools/gcc-mline-20050407/bin/gcc -m64 -c 930106-1.c
930106-1.c: In function ‘f’:
930106-1.c:20: internal compiler error: in gen_reg_rtx, at emit-rtl.c:778
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
                                                                                
This problem was introduced with the following patch, which might
have merely exposed a latent bug:
                                                                                
  http://gcc.gnu.org/ml/gcc-cvs/2005-03/msg01264.html

-- 
           Summary: ICE in gen_reg_rtx for 3 spec tests
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: janis at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org,geoffk at gcc dot gnu
                    dot org
 GCC build triplet: powerpc64-linux
  GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Keywords|                            |ice-on-valid-code
            Summary|ICE in gen_reg_rtx for 3    |[4.1 Regression] ICE in
                   |spec tests                  |gen_reg_rtx for 3 spec tests
   Target Milestone|---                         |4.1.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-07 20:50 -------
-m64 -mcpu=rs64a is enough to reproduce the bug.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-07 20:50:02
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-04-14 18:18 -------
Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:

extern void bar (void *);
extern double x;
                                                                                
void
foo (void)
{
  char buf2 [32][1024];
  bar (buf2 [(int) x]);
}

On IRC pinskia pointed out that powerpc64-linux supports older CPUs by
default than does powerpc-darwin.  The ICE doesn't happen with -mcpu=power3;
I didn't try earlier cpus.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-04-14 19:30 -------
(In reply to comment #2)
> Here's a minimized test case that fails on powerpc64-linux with -m64 -O2:
> On IRC pinskia pointed out that powerpc64-linux supports older CPUs by
> default than does powerpc-darwin.  The ICE doesn't happen with -mcpu=power3;
> I didn't try earlier cpus.

The only 64bit PPC CPU that does not support these optional instruction is the rs64a.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[dje at gcc dot gnu dot org]

------- Additional Comments From dje at gcc dot gnu dot org  2005-04-20 14:18 -------
rs64a does not support it, but rs64b does.  We might want to limit GCC support 
to rs64b.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-22 14:36 -------
Subject: Bug 20813

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dje@gcc.gnu.org	2005-04-22 14:36:37

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: default64.h rs6000.c 
	gcc/doc        : invoke.texi 

Log message:
	PR target/20813
	* config/rs6000/default64.h (TARGET_DEFAULT): Add MASK_PPC_GFXOPT.
	* config/rs6000/rs6000.c (processor_target_table): Rename rs64a to
	rs64.  Add MASK_PPC_GFXOPT to powerpc64 and rs64.
	(rs6000_init_libfuncs): Set TFmode optabs to xlq names if
	TARGET_XL_COMPAT.
	* doc/invoke.texi (PowerPC options): Change rs64a to rs64.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8407&r2=2.8408
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/default64.h.diff?cvsroot=gcc&r1=1.3&r2=1.4
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/rs6000.c.diff?cvsroot=gcc&r1=1.812&r2=1.813
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/doc/invoke.texi.diff?cvsroot=gcc&r1=1.607&r2=1.608



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-04-28 16:58 -------
GCC built with sources that include that patch fails in the same place
building gzip, bzip2, and mesa from SPEC CPU2000 with "-m64 -O2".

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-04-28 18:12 -------
The compilers that I tested that still failed were configured with
--build, --host, --target=powerpc64-linux and --with-cpu=default32.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-04-28 18:52 -------
Subject: Bug 20813

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	dje@gcc.gnu.org	2005-04-28 18:52:22

Modified files:
	gcc            : ChangeLog 
	gcc/config/rs6000: aix43.h aix51.h aix52.h sysv4.h 

Log message:
	PR target/20813
	* config/rs6000/aix43.h (SUBSUBTARGET_SWITCHES, aix64): Add
	MASK_PPC_GFXOPT.
	* config/rs6000/aix51.h (SUBSUBTARGET_SWITCHES, aix64): Same.
	* config/rs6000/aix52.h (SUBSUBTARGET_SWITCHES, aix64): Same.
	* config/rs6000/sysv4.h (SUBTARGET_SWITCHES, 64): Same.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.8514&r2=2.8515
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/aix43.h.diff?cvsroot=gcc&r1=1.36&r2=1.37
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/aix51.h.diff?cvsroot=gcc&r1=1.26&r2=1.27
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/aix52.h.diff?cvsroot=gcc&r1=1.14&r2=1.15
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/rs6000/sysv4.h.diff?cvsroot=gcc&r1=1.159&r2=1.160



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2005-04-28 18:58 -------
OK, the problem is definitely a latent bug.

The problem is that in fix_truncdfsi2, it creates a stack temporary, with

 operands[3] = assign_stack_temp (DImode, GET_MODE_SIZE (DImode), 0);                                                      

which just happens to be something like

(mem/i:DI (plus:SI (reg/f:SI 114 virtual-stack-vars)
        (const_int 32768 [0x8000])) [0 S8 A64])

Uh-oh!  That's not an address!  So when instantiate_virtual_regs_1 notices this, it rewrites it to:

            (clobber (mem/i:DI (plus:SI (reg/f:SI 30 r30)
                        (reg:SI 128)) [0 S8 A64]))
 
but fix_truncdfsi2_internal needs an offsettable operand,

   (clobber (match_operand:DI 3 "memory_operand" "=o"))]

because it plans to use plus_constant on it.

For me, the testcase fails even if I just say "-mcpu=rs64a", there's no need for actual 64-bit pointers.

I guess the right fix is to use adjust_address rather than plus_constant.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[janis at gcc dot gnu dot org]

------- Additional Comments From janis at gcc dot gnu dot org  2005-04-28 20:24 -------
The three SPEC CPU2000 tests build and run successfully with the patch
in comment #8.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2005-04-29 02:03 -------
(In reply to comment #9) 
> I guess the right fix is to use adjust_address rather than plus_constant.

Please try
  http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02820.html
with the additional assignment to any_change described in 
  http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02830.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2005-04-29 22:11 -------
I have a fix for this.

The problem is like this:

- Sometimes, assign_stack_temp can generate an invalid memory address.  Even if the address was 
always valid, it's not always offsettable, which is what this pattern needs.
- instantiate_virtual_regs_1 might not be supposed to be making the address valid, but it's not 
unreasonable for it or something else to try.  If the address isn't valid, the insn can't be recognized, so 
it's not like we can try to keep the invalid address around until reload.
- After reload, the address had better be offsettable, since it's "=o".  Before reload, it might be 
offsettable, or we might be able to offset it anyway (if no_new_pseudos is clear).

I was mistaken earlier, it was a regression in my patch.  The regression was caused by a line which I 
didn't notice in a define_insn_and_split, changing '&& reload_completed' to '&& 1'.  (That's now two 
stray changes in that patch that shouldn't have been there, sorry about that.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |geoffk at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813

[Bug target/20813] [4.1 Regression] ICE in gen_reg_rtx for 3 spec tests

[geoffk at gcc dot gnu dot org]

------- Additional Comments From geoffk at gcc dot gnu dot org  2005-05-03 00:58 -------
Should be fixed by
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00130.html


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20813