This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[rth@cygnus.com: Re: compilation error]


Applied.


r~


----- Forwarded message from Richard Henderson <rth@cygnus.com> -----

Date: Tue, 23 May 2000 18:18:12 -0700
From: Richard Henderson <rth@cygnus.com>
To: Chandra Chavva <cchavva@cygnus.com>
Cc: gcc-local@cygnus.com
Subject: Re: compilation error

On Tue, May 23, 2000 at 03:49:43PM -0700, Chandra Chavva wrote:

[ mips64-elf target ]

> (insn 18 197 20 (parallel[ 
>             (set (mem/s:BLK (reg:SI 3 v1) 0)
>                 (mem/s/u:BLK (lo_sum:SI (reg:SI 2 v0)
>                         (symbol_ref:SI ("*$LC0"))) 0))
>             (clobber (reg:SI 5 a1))
>             (clobber (reg:SI 6 a2))
>             (clobber (reg:SI 7 a3))
>             (clobber (reg:SI 8 t0))
>             (use (const_int 8 [0x8]))
>             (use (const_int 4 [0x4]))
>             (use (const_int 0 [0x0]))
>         ] ) 197 {movstrsi_internal} (insn_list 12 (insn_list 5 (nil)))
>     (nil))
> test3.c:19: Internal compiler error in `reload_cse_simplify_operands',

This appears to be a latent problem that is victim of the recent
unsignedness spree.  Previously GET_MODE_SIZE was an int, and
so 0 - 1 == -1.  Now we have 0u - 1 == 0x00000000ffffffff, which
is not a valid offset.

I don't know enough about the details of the mips movstr patterns
to know how bounded the size can be.  Nor if this sort of thing
is latent in other ports as well.

It's entirely possible that the Proper thing to do is to abort and
disallow this sort of nonsense entirely.  However, this solution
seems no worse than what we had before.

Opinions?


r~

	* recog.c (offsettable_address_p): If mode size is zero, assume
	BIGGEST_ALIGNMENT.

Index: recog.c
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/recog.c,v
retrieving revision 1.90
diff -c -p -d -r1.90 recog.c
*** recog.c	2000/05/23 17:25:40	1.90
--- recog.c	2000/05/24 01:06:42
*************** offsettable_address_p (strictp, mode, y)
*** 1847,1852 ****
--- 1847,1853 ----
    rtx *y2;
    int (*addressp) PARAMS ((enum machine_mode, rtx)) =
      (strictp ? strict_memory_address_p : memory_address_p);
+   unsigned int mode_sz = GET_MODE_SIZE (mode);
  
    if (CONSTANT_ADDRESS_P (y))
      return 1;
*************** offsettable_address_p (strictp, mode, y)
*** 1857,1862 ****
--- 1858,1870 ----
    if (mode_dependent_address_p (y))
      return 0;
  
+   /* ??? How much offset does an offsettable BLKmode reference need?
+      Clearly that depends on the situation in which it's being used.
+      However, the current situation in which we test 0xffffffff is
+      less than ideal.  Caveat user.  */
+   if (mode_sz == 0)
+     mode_sz = BIGGEST_ALIGNMENT / BITS_PER_UNIT;
+ 
    /* If the expression contains a constant term,
       see if it remains valid when max possible offset is added.  */
  
*************** offsettable_address_p (strictp, mode, y)
*** 1865,1871 ****
        int good;
  
        y1 = *y2;
!       *y2 = plus_constant (*y2, GET_MODE_SIZE (mode) - 1);
        /* Use QImode because an odd displacement may be automatically invalid
  	 for any wider mode.  But it should be valid for a single byte.  */
        good = (*addressp) (QImode, y);
--- 1873,1879 ----
        int good;
  
        y1 = *y2;
!       *y2 = plus_constant (*y2, mode_sz - 1);
        /* Use QImode because an odd displacement may be automatically invalid
  	 for any wider mode.  But it should be valid for a single byte.  */
        good = (*addressp) (QImode, y);
*************** offsettable_address_p (strictp, mode, y)
*** 1884,1890 ****
       of the specified mode.  We assume that if Y and Y+c are
       valid addresses then so is Y+d for all 0<d<c.  */
  
!   z = plus_constant_for_output (y, GET_MODE_SIZE (mode) - 1);
  
    /* Use QImode because an odd displacement may be automatically invalid
       for any wider mode.  But it should be valid for a single byte.  */
--- 1892,1898 ----
       of the specified mode.  We assume that if Y and Y+c are
       valid addresses then so is Y+d for all 0<d<c.  */
  
!   z = plus_constant_for_output (y, mode_sz - 1);
  
    /* Use QImode because an odd displacement may be automatically invalid
       for any wider mode.  But it should be valid for a single byte.  */

----- End forwarded message -----

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]