[Bug target/21041] New: ICE: output_operand: Cannot decompose address

[Bug target/21041] New: ICE: output_operand: Cannot decompose address

[matz at suse dot de]

The below testcase is extracted from smpeg.  It's C++.  Compile it like 
so: 
 
% ./gcc/cc1plus -O2 -fPIC video.ii 
video.cpp: In function 'int ParseMacroBlock(VidStream*)': 
video.cpp:2205: internal compiler error: output_operand: Cannot decompose 
address. 
 
I wasn't able to make the functions much smaller than this (didn't try 
reducing the headers, though).

-- 
           Summary: ICE: output_operand: Cannot decompose address
           Product: gcc
           Version: 4.0.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: target
        AssignedTo: uweigand at de dot ibm dot com
        ReportedBy: matz at suse dot de
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: {s390,s390x}-linux-gnu


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

[Bug target/21041] ICE: output_operand: Cannot decompose address

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-15 08:19 -------
Created an attachment (id=8641)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8641&action=view)
Preprocessed source for the ICE


-- 


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

[Bug target/21041] ICE: output_operand: Cannot decompose address

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-04-15 08:20 -------
Forgot to say, the preprocessed file is for s390x.  On s390 the same happens, 
though. 

-- 


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[belyshev at depni dot sinp dot msu dot ru]

------- Additional Comments From belyshev at depni dot sinp dot msu dot ru  2005-04-15 10:21 -------
// smaller testcase, compile with -O2 -fPIC

struct vs {
  int h, w, k, q;
  short int dct_recon[8];
};

void bar (struct vs* v)
{
  char *s;
  short int *b;
  int x, y, z, r, i, j;

  for (i = 0; i < 6; i++)
    if (v->q)
      {
	if (i)
	  {
	    if (v->k > v->h)
	      j = 1;
      
	    if (v->k > v->w)
	      j += 1;
	  }

	if (j)
	  {
	    *s++ = 0;
	    if (!z)
	      {
		for (r = 0; r < 8; r++)
		  {
		    b = &(v->dct_recon[r]);
		    s[0] += b[0];
		    s[1] += b[1];
		    s[2] += b[2];
		    s[3] += b[3];
		    s[4] += b[4];
		    s[5] += b[5];
		    s[6] += b[6];
		    s[7] += b[7];
		  }
	      }
	  }
      }
}


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2005-04-15 10:21:04
               date|                            |
            Summary|ICE: output_operand: Cannot |[4.0 Regression] ICE:
                   |decompose address           |output_operand: Cannot
                   |                            |decompose address
   Target Milestone|---                         |4.0.1


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[uweigand at gcc dot gnu dot org]

------- Additional Comments From uweigand at gcc dot gnu dot org  2005-04-16 15:48 -------
The problem originates in find_reloads_subreg_address, which decides
to widen access to a memory reference.  The instruction we have is:

(insn 129 127 130 10 (parallel [
            (set (reg:SI 106)
                (plus:SI (subreg:SI (reg:QI 104) 0)
                    (subreg:SI (reg:QI 105) 0)))
            (clobber (reg:CC 33 %cc))
        ]) 143 {addsi3} (insn_list:REG_DEP_TRUE 128 (insn_list:REG_DEP_TRUE 127
(nil)))
    (expr_list:REG_DEAD (reg:QI 104)
        (expr_list:REG_DEAD (reg:QI 105)
            (expr_list:REG_UNUSED (reg:CC 33 %cc)
                (nil)))))

and register 104 is equivalent to a memory slot:

(insn 127 128 129 10 (set (reg:QI 104)
        (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])) 53 {*movqi}
(insn_list:REG_DEP_TRUE 81 (insn_list:REG_DEP_TRUE 88 (insn_list:REG_DEP_TR
UE 95 (insn_list:REG_DEP_TRUE 102 (insn_list:REG_DEP_TRUE 109
(insn_list:REG_DEP_TRUE 116 (insn_list:REG_DEP_TRUE 123 (nil))))))))
    (expr_list:REG_EQUIV (mem:QI (reg/f:SI 47 [ pretmp.10 ]) [0 S1 A8])
        (nil)))

Now, reg 104 does not get a hard reg assigned. However, register 47 gets
assigned hard reg 0, which is not valid in a memory address.

Because register 104 is now equivalent to an invalid memory reference,
find_reloads_toplev calls find_reloads_subreg_address on the paradoxical
(subreg:SI (reg:QI 104)).

That routine thinks it can replace the subreg with an adjusted equivalent
memory reference (mem:SI (plus (reg 0) (const_int -3))).

It then calls find_reloads_address on that address.  Now, this address
is invalid for *two* reasons: register 0 cannot be used as base register,
and negative displacements are invalid.  find_reloads_address is unable
to cope with this combination, and returns with an address that is still
invalid.

[ If LEGITIMIZE_RELOAD_ADDRESS is active, it fixes the negative displacement
but keeps register 0.  If I disable LEGITIMIZE_RELOAD_ADDRESS, the default
find_reloads_address behaviour will reload register 0, but keep the invalid
displacement. ]

As a workaround, I can add code to LEGITIMIZE_RELOAD_ADDRESS that fixes
both issues and results in a valid address, fixing the ICE.  However, this
has two problems:

1. According to my understanding, L_R_A should never be required for
correctness, but only bring extra performance.  Thus find_reloads_address
alone should also be able to fix the problem.

2. The whole business of widening access to a memory slot is questionable
in this case: if register 47 were to point to the start of a page of memory
preceded by unmapped address space, the widened access would crash.  I had
thought that for this reason, only accesses to *stack slots* can be widened;
scan_paradoxical_subregs would make sure such stack slots are aligned 
properly.  However, in this case just some random memory access is widened.


As a final comment: both test cases in this PR are strictly speaking
invalid C or C++, because uninitialized variables are accessed.  I was
unable to modify the test cases to valid C/C++.  Does the original
unreduced source code also have uninitialized variables?  There have
been some issues in the past where reload would handle uninitialized
pseudos correctly ...

-- 


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[matz at suse dot de]

------- Additional Comments From matz at suse dot de  2005-06-03 14:56 -------
There are some maybe-uninitialized vars warnings.  But if I fix them by 
zeroing the vars it still ICEs.  I can't find other uninitialized vars. 
It might be, that there are uninitialized struct members, but they 
shouldn't affect the problem.  Just for reference I've added the full 
unreduced testcase (with no uninited vars anymore).  On s390x it ICEs with 
-O2 -fPIC . 

-- 


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[uweigand at gcc dot gnu dot org]

------- Additional Comments From uweigand at gcc dot gnu dot org  2005-06-06 15:57 -------
Here's another reduced test case, this time without
uninitialized variables:

// ICEs with -O2 -fPIC

struct args
{
  short int matrix[8][8];
  char **current;
};

int test (struct args *args, char *init, int a, int b)
{
  int i, j, k;

  if (!args || a > b || a < 0)
    return -1;

  for (i = 0; i < 2; i++)
    {
      char *dest = *args->current;
      char *p = dest;

      for (j = 0; j < 8; j++)
        *p++ = *init++;

      for (k = 0; k < 8; k++)
        {
          short int *blockvals = &args->matrix[k][0];
          dest[0] += blockvals[0];
          dest[1] += blockvals[1];
          dest[2] += blockvals[2];
          dest[3] += blockvals[3];
          dest[4] += blockvals[4];
          dest[5] += blockvals[5];
          dest[6] += blockvals[6];
          dest[7] += blockvals[7];
       }
    }

  return 1;
}

-- 


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-07-06 17:02 -------
Postponed until 4.0.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.1                       |4.0.2


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

[Bug target/21041] [4.0 Regression] ICE: output_operand: Cannot decompose address

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.0.2                       |4.0.3


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