Re: Miscellaneous testsuitsuite failures under hpux 10.20

[Jeffrey A Law <law at cygnus dot com>]

  In message <200006212239.SAA17136@hiauly1.hia.nrc.ca>you write:
  > > 
  > > 
  > >   In message <200006211636.MAA05809@hiauly1.hia.nrc.ca>you write:
  > >   > > 2) Fatal signal 11
  > >   > > 
  > >   > > gcc/ /xxx/gnu/gcc-2.96/gcc/testsuite/gcc.c-torture/execute/920501-6
  > .c  -w
  > >   >   -O3 -fssa   -lm   -threads -o /xxx/gnu/gcc-2.96/objdir/gcc/testsuit
  > e/9205
  > >   > 01-6.x7    (timeout = 300)
  > >   > > xgcc: Internal compiler error: program cc1 got fatal signal 11^M
  > >   > > compiler exited with status 1
  > >   > > output is:
  > >   > > xgcc: Internal compiler error: program cc1 got fatal signal 11^M
  > >   > 
  > >   > The problem is a null pointer returned at line 1230 of loop.c
  > >   > (libcall_other_reg).  The rtl from the gcse stage that causes the
  > >   > problem is:
  > >   > 
  > >   > (insn/i 107 106 108 (set (reg:DI 153)
  > >   >         (reg:DI 153)) 122 {movstrsi_internal+10} (nil)
  > >   >     (insn_list:REG_RETVAL 104 (expr_list:REG_EQUAL (lshiftrt:DI (reg:
  > DI 122
  > >   > )
  > >   >                 (const_int 1 [0x1]))
  > >   >             (nil))))
  > >   > 
  > >   > The resulting value for note is:
  > >   > 
  > >   > (gdb) p debug_rtx(note)
  > >   > 
  > >   > (insn_list:REG_RETVAL 104 (expr_list:REG_EQUAL (lshiftrt:DI (reg:DI 1
  > 22)
  > >   >             (const_int 1 [0x1]))
  > >   >         (nil)))
  > >   > 
  > >   > and the initial value of p is:
  > >   > 
  > >   > (gdb) p debug_rtx(p)
  > >   > (insn/v/i 104 0 0 (clobber (reg:DI 153)) -1 (nil)
  > >   >     (expr_list:REG_UNUSED (reg:DI 153)
  > >   >         (insn_list:REG_LIBCALL 107 (nil))))
  > >   > 
  > >   > As can be seen, the next instruction is 0 rather than 107.  Thus, eit
  > her
  > >   > find_reg_note needs to be fixed to handle this situation differently,
  > >   > or libcall_other_reg must be prepared for a null pointer.  Thoughts?
  > > This shows that insn 104 was deleted.  That's incorrect behavior.  Find o
  > ut
  > > where insn 104 was deleted.
  > 
  > The insn 104 was deleted in the ussa pass.
Definitely a bug in the translation from ssa to normal form.  It is never
OK to delete individual insns out of a libcall sequence like that.

The next step is to determine why the conversion from ssa to normal form
deleted that insn and stop it from happening in the future.
jeff