[Bug middle-end/24036] New: [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[Bug middle-end/24036] New: [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[rmansfield at qnx dot com]

ICE when using -mfloat-gprs=double with -mspe=no. Found in the e500 branch,
reproducible in mainline.

Test case:

typedef double _Complex _Dcomplex;

double (cabs)(_Dcomplex x) { }

[rmansfield@bender rmansfield]$
/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/bin/powerpc-linux-gnuspe-gcc
-mfloat-gprs=double -mcpu=8548 ~/cabs.i -c -mspe=no -v

Using built-in specs.

Target: powerpc-linux-gnuspe

Configured with:
/home/rmansfield/crosstool-0.28-rc37/build/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/gcc-head/configure
--target=powerpc-linux-gnuspe --host=i686-host_pc-linux-gnu
--prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5
--with-local-prefix=/home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/powerpc-linux-gnuspe
--disable-multilib --with-newlib --without-headers --disable-nls
--enable-threads=no --enable-symvers=gnu --enable-__cxa_atexit
--enable-languages=c --disable-shared

Thread model: single

gcc version 4.1.0 20050917 (experimental)

 /home/rmansfield/crosstool/powerpc-linux-gnuspe/gcc-head-glibc-2.3.5/libexec/gcc/powerpc-linux-gnuspe/4.1.0/cc1
-fpreprocessed /home/rmansfield/cabs.i -quiet -dumpbase cabs.i
-mfloat-gprs=double -mcpu=8548 -mspe=no -auxbase cabs -version -o /tmp/ccNYZQDL.s

GNU C version 4.1.0 20050917 (experimental) (powerpc-linux-gnuspe)

        compiled by GNU C version 3.3.3 20040412 (Red Hat Linux 3.3.3-7).

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096

Compiler executable checksum: 947d94ba0d127e0ee2614bdf9bacf926

/home/rmansfield/cabs.i: In function 'cabs':

/home/rmansfield/cabs.i:3: internal compiler error: in
subreg_offset_representable_p, at rtlanal.c:3143

Please submit a full bug report,

with preprocessed source if appropriate.

See <URL:http://gcc.gnu.org/bugs.html> for instructions.

> If this is reproducible in mainline, could you submit this bug in bugzilla and 
> assign it to me?

> Thanks
> Aldy

-- 
           Summary: [e500] ICE in subreg_offset_representable_p, at
                    rtlanal.c:3143
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: middle-end
        AssignedTo: aldyh at redhat dot com
        ReportedBy: rmansfield at qnx dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-host_pc-linux-gnu
  GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: powerpc-linux-gnuspe


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

[Bug middle-end/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-09-23 16:59 -------
*** Bug 24038 has been marked as a duplicate of this bug. ***

-- 


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |target
           Keywords|                            |ice-on-valid-code


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[jsm28 at gcc dot gnu dot org]

------- Comment #7 from jsm28 at gcc dot gnu dot org  2006-12-01 02:25 -------
Subject: Bug 24036

Author: jsm28
Date: Fri Dec  1 02:25:22 2006
New Revision: 119395

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119395
Log:
2006-12-01  Joseph Myers  <joseph@codesourcery.com>
            David Edelsohn  <edelsohn@gnu.org>

        PR target/24036
        * doc/tm.texi (HARD_REGNO_NREGS_HAS_PADDING,
        HARD_REGNO_NREGS_WITH_PADDING): Document new target macros.
        * defaults.h (HARD_REGNO_NREGS_HAS_PADDING,
        HARD_REGNO_NREGS_WITH_PADDING): Define.
        * config/i386/i386.h (HARD_REGNO_NREGS_HAS_PADDING,
        HARD_REGNO_NREGS_WITH_PADDING): Define.
        * rtlanal.c (subreg_regno_offset, subreg_offset_representable_p):
        Use new macros to detect modes with holes; do not look at integer
        units.
        (subreg_offset_representable_p): Check for and disallow cases
        where the modes use different numbers of bits from registers.
        * config/rs6000/rs6000.c (rs6000_emit_move): Handle TFmode
        constant for soft-float.
        (rs6000_hard_regno_nregs): Use UNITS_PER_FP_WORD for e500 GPRs
        containing doubles.
        (rs6000_split_multireg_move): Use DFmode reg_mode for TFmode moves
        in E500 double case.
        * config/rs6000/rs6000.md (movtf): Allow soft-float.
        (movtf_softfloat): New.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.h
    trunk/gcc/config/rs6000/rs6000.c
    trunk/gcc/config/rs6000/rs6000.md
    trunk/gcc/defaults.h
    trunk/gcc/doc/tm.texi
    trunk/gcc/rtlanal.c


-- 


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[jsm28 at gcc dot gnu dot org]

------- Comment #6 from jsm28 at gcc dot gnu dot org  2006-11-23 00:16 -------
Patch was discussed at
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00451.html
and had some objections from Geoff Keating.

I've come across another problem case and am testing another possible patch to
address both cases.  If you take an SImode subreg of a DFmode register, offset
4, that is the low word of the register and so is representable and
subreg_regno_offset should return 0.  But the conversion to integer units means
that it acts like taking an SImode subreg of a DImode value (and so returns 1,
taking the wrong register).  I think the conversion to integer units is simply
wrong in these cases.


-- 

jsm28 at gcc dot gnu dot org changed:

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


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[dje at gcc dot gnu dot org]

------- Comment #5 from dje at gcc dot gnu dot org  2006-07-17 02:05 -------
Created an attachment (id=11902)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11902&action=view)
consistently calculate nregs for FLOAT_MODES


-- 


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[dje at gcc dot gnu dot org]

------- Comment #4 from dje at gcc dot gnu dot org  2006-07-17 01:43 -------
Double Complex on e500 with double GPRs fundamentally does not interact well
with GCC's current design.  GCC does not want to have a double placed in the
same register that can contain an int if the width of the register for ints
cannot span the width of the register for float.

rs6000_hard_regno_nregs() can cover the e500 double case with:

  if (TARGET_E500_DOUBLE && FLOAT_MODE_P (mode))
    return (GET_MODE_SIZE (mode) + UNITS_PER_FP_WORD - 1) / UNITS_PER_FP_WORD;

which fixes the first dubreg_offset_representable_p() assert, but subreg_offset
with double nregs foir regno != int nregs for same regno intends this case for
"holes", e.g., XFmode spanning three 32-bit float words but four 32-bit int
words.

(In this example, xmode is DCmode and ymode is DFmode.)

For this special case, the function overrides the default (and correct) nregs

nregs_xmode = hard_regno_nregs[xregno][xmode];

with

nregs_xmode_unit_int * GET_MODE_NUNITS (xmode)

which is twice the number of units.  However, ymode is calculated the normal
way.  Hilarity ensues, e.g.,

  gcc_assert ((mode_multiple % nregs_multiple) == 0);

fails.


-- 


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[dje at gcc dot gnu dot org]

------- Comment #3 from dje at gcc dot gnu dot org  2006-07-14 19:11 -------
This is because the E500 DOUBLE support wasn't prepared for complex doubles.

Index: rs6000.c
===================================================================
--- rs6000.c    (revision 115431)
+++ rs6000.c    (working copy)
@@ -3638,8 +3638,13 @@
   if (FP_REGNO_P (regno))
     return (GET_MODE_SIZE (mode) + UNITS_PER_FP_WORD - 1) / UNITS_PER_FP_WORD;

-  if (TARGET_E500_DOUBLE && mode == DFmode)
-    return 1;
+  if (TARGET_E500_DOUBLE)
+    {
+      if (mode == DFmode)
+       return 1;
+      if (mode == DCmode)
+       return 2;
+    }

   if (SPE_SIMD_REGNO_P (regno) && TARGET_SPE && SPE_VECTOR_MODE (mode))
     return (GET_MODE_SIZE (mode) + UNITS_PER_SPE_WORD - 1) /
UNITS_PER_SPE_WORD;

I could make this cuter with tests for FLOAT_MODE_P, but I am worried about the
effect on SPE vector modes and there are not enough mode to warrant a case
table, so just use an explicit test.


-- 

dje at gcc dot gnu dot org changed:

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


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

[Bug target/24036] [e500] ICE in subreg_offset_representable_p, at rtlanal.c:3143

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-06-30 05:47 -------
Confirmed on the mainline.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.2.0
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-30 05:47:59
               date|                            |


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