[Bug bootstrap/29825] New: ICE in

[Bug bootstrap/29825] New: ICE in

[debian-gcc at lists dot debian dot org]

the fix for PR middle-end/28915 causes a bootstrap failure with 4.1 20061113 on
i486 (using the Debian build); didn't yet check with a vanilla 4.1 branch or
the fedora 4.1 branch.

  Matthias

./xgcc -B./ -B/usr/i486-linux-gnu/bin/ -isystem /usr/i486-linux-gnu/include
-isystem /usr/i486-linux-gnu/sys-include
-L/home/packages/gcc/4.1/gcc-4.1-4.1.1ds2/build/gcc/../ld -O2  -O2 -g -O2 
-DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -I. -I. -I../../src/gcc
-I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include 
-fexceptions -fvisibility=hidden -DHIDE_EXPORTS -c ../../src/gcc/unwind-dw2.c
-o libgcc/./unwind-dw2.o
../../src/gcc/unwind-dw2.c: In function 'uw_install_context_1':
../../src/gcc/unwind-dw2.c:1357: error: unrecognizable insn:
(insn:HI 157 44 158 4 (set (reg:SI 98)
        (unspec:SI [
                (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x4042e6c0 dwarf_reg_size_table>)
            ] 1)) -1 (nil)
    (nil))
../../src/gcc/unwind-dw2.c:1357: internal compiler error: in extract_insn, at
recog.c:2084
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


-- 
           Summary: ICE in
           Product: gcc
           Version: 4.1.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: debian-gcc at lists dot debian dot org


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

[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

[debian-gcc at lists dot debian dot org]

------- Comment #1 from debian-gcc at lists dot debian dot org  2006-11-14 08:18 -------
reverting the fix for PR28915 fixes the bootstrap error

2006-11-12  Jason Merrill  <jason@redhat.com>
    Andrew Pinski <pinskia@physics.uc.edu>

PR middle-end/28915
* gimplify.c (gimplify_init_constructor): Don't reduce TREE_CONSTANT
vector ctors.
* tree-cfg.c (verify_expr): Don't look into TREE_CONSTANT
vector ctors.
* expmed.c (make_tree): Handle CONST, SYMBOL_REF.
* tree.c (build_vector): Handle non-_CST elements.


-- 

debian-gcc at lists dot debian dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in                      |ICE in extract_insn, at
                   |                            |recog.c:2084 (unrecognizable
                   |                            |insn)


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

[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-11-14 08:21 -------
(In reply to comment #1)
> reverting the fix for PR28915 fixes the bootstrap error

This patch should not have any affect on bootstrap as there are no vectors
usage inside GCC.


-- 


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

[Bug bootstrap/29825] ICE in extract_insn, at recog.c:2084 (unrecognizable insn)

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-11-14 08:26 -------
building a plain 4.1 branch to prove it.


-- 


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

[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2006-11-14 09:03 -------
Yep, and the aforementioned patch is indeed the culprit.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |blocker
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-11-14 09:03:07
               date|                            |
            Summary|ICE in extract_insn, at     |[4.1 regression] ICE in
                   |recog.c:2084 (unrecognizable|extract_insn, at
                   |insn)                       |recog.c:2084
   Target Milestone|---                         |4.1.2


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

[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-11-14 09:06 -------
Looking into it, a bit more. But as far as I can tell this is a latent bug in
the x86 back-end.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-11-14 09:40 -------
This is a bug in loop.c ... which is why it works in 4.2.0 and above.


-- 


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

[Bug bootstrap/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-11-14 09:46 -------
So the problem is that loop.c creates a tree for:
(plus:SI (reg:SI 3 bx)
    (const:SI (unspec:SI [
                (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0xb7ce10b0 dwarf_reg_size_table>)
            ] 1)))

From:
5106    expand_mult_add (rtx x, rtx target, rtx mult, rtx add, enum
machine_mode mode,
5107                     int unsignedp)



(gdb) p debug_rtx(x)
(const_int 1 [0x1])
$6 = void
(gdb) p debug_rtx(mult)
(const_int 1 [0x1])
$7 = void
(gdb) p debug_rtx(add)
(plus:SI (reg:SI 3 bx)
    (const:SI (unspec:SI [
                (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0xb7ce10b0 dwarf_reg_size_table>)
            ] 1)))


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-11-14 09:53 -------
Hmm, isn't movl %eax, dwarf_reg_size_table@GOTOFF a valid way to have an
offset?



Reduced testcase:
struct _Unwind_Context
{
  void *reg[18];
};
static unsigned char dwarf_reg_size_table[18];
uw_install_context_1 (void *current,
        struct _Unwind_Context *target)
{
  long i;
  for (i = 0; i < 17; ++i)
    {
      void *t = target->reg[i];
      if (t)
        __builtin_memcpy (current, t, dwarf_reg_size_table[i]);
    }
}



-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|bootstrap                   |target
 GCC target triplet|                            |i?86-*-linux-gnu


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-11-14 09:57 -------
(In reply to comment #8)
> Hmm, isn't movl %eax, dwarf_reg_size_table@GOTOFF a valid way to have an
> offset?

gas accepts that as valid so I think GCC should accept this.  I am now going to
bed but I am also going to say this is a latent bug in the x86 back-end.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2006-11-14 10:45 -------
The problem is in the make_tree change of PR28915.
make_tree is called with (const (unspec (something) ) ), before make_tree
would just create a dummy VAR_DECL with DECL_RTL set to this, but now
calls make_tree recursively and thus returns a dummy VAR_DECL with DECL_RTL
set to (unspec (something) ) - note that CONST is lost.
It is then folded and expanded, but CONST is never added back and i386 backend
relies on it (and I believe other backends have similar requirements).
I don't know why exactly the make_tree change was done, but certainly
it should be limited to RTLs inside CONST that the middle-end groks fully.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[rguenth at gcc dot gnu dot org]

------- Comment #11 from rguenth at gcc dot gnu dot org  2006-11-14 11:11 -------
The reduced testcase only fails on i?86, bootstrap also fails on x86_64 with
the same error.

At least (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x2af3f74a6580 dwarf_reg_size_table>) is not a valid PIC address (it's only one
in 64bit mode).

from loop.c we enter ix86_expand_move (via gen_movis) with an operand1 of

(unspec:SI [
        (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x2b38cd3da580 dwarf_reg_size_table>)
    ] 1)

which we don't handle.

We reach there through loop.c:gen_add_mult called with

#11 0x000000000091e99b in gen_add_mult (b=0x2b38cd2ee410, m=0x2b38cd2ee410, 
    a=0x2b38cd49bdc0, reg=0x2b38cd49bd20)
    at /space//rguenther/src/svn/gcc-4_1-branch/gcc/loop.c:9223
9223      result = expand_mult_add (b, reg, m, a, GET_MODE (reg), 1);
(gdb) call debug_rtx (b)
(const_int 1 [0x1])
(gdb) call debug_rtx (m)
(const_int 1 [0x1])
(gdb) call debug_rtx (a)
(plus:SI (plus:SI (reg:SI 3 bx)
        (const_int -1 [0xffffffffffffffff]))
    (const:SI (unspec:SI [
                (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x2b38cd3da580 dwarf_reg_size_table>)
            ] 1)))
(gdb) call debug_rtx (reg)
(reg:SI 82)

via expmed.c:expand_mult_add we go through expanding a tree (ugh) which looks
then like

(gdb) call debug_tree (result)
 <plus_expr 0x2b38cd499410
    type <integer_type 0x2b38cd2f8580 unsigned int public unsigned SI
        size <integer_cst 0x2b38cd2e9a50 constant invariant 32>
        unit size <integer_cst 0x2b38cd2e9570 constant invariant 4>
        align 32 symtab 0 alias set -1 precision 32 min <integer_cst
0x2b38cd2e9b40 0> max <integer_cst 0x2b38cd2e9b10 4294967295>>

    arg 0 <var_decl 0x2b38cd49c210 D.1348 type <integer_type 0x2b38cd2f8580
unsigned int>
        used unsigned SI file t.i line 16 size <integer_cst 0x2b38cd2e9a50 32>
unit size <integer_cst 0x2b38cd2e9570 4>
        align 32
        (reg:SI 3 bx)>
    arg 1 <var_decl 0x2b38cd49c160 D.1347 type <integer_type 0x2b38cd2f8580
unsigned int>
        used unsigned SI file t.i line 16 size <integer_cst 0x2b38cd2e9a50 32>
unit size <integer_cst 0x2b38cd2e9570 4>
        align 32
        (unspec:SI [
        (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x2b38cd3da580 dwarf_reg_size_table>)
    ] 1)>>

which is where we get the plain UNSPEC from.  In loop.c:scan_loop we
propagate the load into its use which is the start of the problems.

We then call validate_replace_rtx with
(gdb) call debug_rtx (from)
(reg/f:SI 72)
(gdb) call debug_rtx (to)
(plus:SI (reg:SI 3 bx)
    (const:SI (unspec:SI [
                (symbol_ref:SI ("dwarf_reg_size_table") [flags 0x2] <var_decl
0x2b22d66b7580 dwarf_reg_size_table>)
            ] 1)))
(gdb) call debug_rtx (insn)
(insn 32 31 34 (parallel [
            (set (reg:SI 71)
                (plus:SI (reg:SI 66 [ ivtmp.32 ])
                    (reg/f:SI 72)))
            (clobber (reg:CC 17 flags))
        ]) 208 {*addsi_1} (nil)
    (nil))

In loop.c we go through lengths of discovering REG_EQUAL notes supposedly
to use them as src in those operations.  And indeed

Index: loop.c
===================================================================
*** loop.c      (revision 118809)
--- loop.c      (working copy)
*************** scan_loop (struct loop *loop, int flags)
*** 1313,1326 ****
                      && ! modified_between_p (SET_SRC (set), p, user)
                      && no_labels_between_p (p, user)
                      && validate_replace_rtx (SET_DEST (set),
!                                              SET_SRC (set), user))
                    {
                      /* Replace any usage in a REG_EQUAL note.  Must copy
                         the new source, so that we don't get rtx sharing
                         between the SET_SOURCE and REG_NOTES of insn p.  */
                      REG_NOTES (user)
                        = replace_rtx (REG_NOTES (user), SET_DEST (set),
!                                      copy_rtx (SET_SRC (set)));

                      delete_insn (p);
                      for (i = 0; i < LOOP_REGNO_NREGS (regno, SET_DEST (set));
--- 1313,1326 ----
                      && ! modified_between_p (SET_SRC (set), p, user)
                      && no_labels_between_p (p, user)
                      && validate_replace_rtx (SET_DEST (set),
!                                              src, user))
                    {
                      /* Replace any usage in a REG_EQUAL note.  Must copy
                         the new source, so that we don't get rtx sharing
                         between the SET_SOURCE and REG_NOTES of insn p.  */
                      REG_NOTES (user)
                        = replace_rtx (REG_NOTES (user), SET_DEST (set),
!                                      copy_rtx (src));

                      delete_insn (p);
                      for (i = 0; i < LOOP_REGNO_NREGS (regno, SET_DEST (set));

seems to fix this particular testcase.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[jakub at gcc dot gnu dot org]

------- Comment #12 from jakub at gcc dot gnu dot org  2006-11-14 11:43 -------
While that can help in this case, I think letting make_tree/expand_expr combo
create invalid RTL is very dangerous (and, at least from i386 backend POV,
some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
guarantees that wherever it creates them it adds the CONST around).


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[ebotcazou at gcc dot gnu dot org]

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2006-11-14 11:48 -------
> While that can help in this case, I think letting make_tree/expand_expr combo
> create invalid RTL is very dangerous (and, at least from i386 backend POV,
> some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
> guarantees that wherever it creates them it adds the CONST around).

FWIW I agree.  Branches are not the right place to try out this kind of things.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-11-14 16:34 -------
(In reply to comment #13)
> > While that can help in this case, I think letting make_tree/expand_expr combo
> > create invalid RTL is very dangerous (and, at least from i386 backend POV,
> > some of the PIC UNSPECs not surrounded by CONST are invalid, the backend
> > guarantees that wherever it creates them it adds the CONST around).

Did you read what I wrote, I said it is not valid, the x86 back-end should
really be accepting it?


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2006-11-14 17:14 -------
Created an attachment (id=12619)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12619&action=view)
patch

This one passes a C bootstrap & regtest on x86_64.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[jason at gcc dot gnu dot org]

------- Comment #16 from jason at gcc dot gnu dot org  2006-11-14 18:21 -------
(In reply to comment #15)
> patch

Please apply this patch to 4.2 and the trunk.  I've reverted my patch on the
4.1 branch, as it seems to be too risky there.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[ebotcazou at gcc dot gnu dot org]

------- Comment #17 from ebotcazou at gcc dot gnu dot org  2006-11-14 19:45 -------
> Please apply this patch to 4.2 and the trunk.  I've reverted my patch on the
> 4.1 branch, as it seems to be too risky there.

Have you really done so?


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[debian-gcc at lists dot debian dot org]

------- Comment #18 from debian-gcc at lists dot debian dot org  2006-11-14 21:09 -------
(In reply to comment #16)
> I've reverted my patch on the
> 4.1 branch, as it seems to be too risky there.

afaics the patch is not yet reverted.

  Matthias


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[jason at redhat dot com]

------- Comment #19 from jason at redhat dot com  2006-11-15 02:07 -------
Subject: Re:  [4.1 regression] ICE in extract_insn, at recog.c:2084

OK, now I've really reverted the patch.  Silly svn resolved...

Jason


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2006-11-15 07:37 -------
Looking at i386 backend, also (const (plus (unspec (something)) (const_int)))
is special (a whole bunch of routines rely on the unspec being surrounded
by CONST, optionally with a PLUS in there).
Not sure if make_tree should try to fallback whenever it sees this too
(safer option), or if it e.g. can return dummy VAR_DECL
with (const (unspec (something))) plus the constant.
An, other backends need auditing what exactly they do with CONST.


-- 


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

[Bug target/29825] [4.1 regression] ICE in extract_insn, at recog.c:2084

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2006-11-25 02:33 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

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


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