Re: Bogus rtx generated?

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

  In message <199803161156.DAA00822@netcom9.netcom.com>you write:
  > 
  > I'm tracking down a bug which causes gcc to crash; it looks like reload is
  > crashing when trying to generate reloads for the following rtx:
  > 
  > (insn 349 33 350 (parallel[
  >             (set (subreg:SI (reg/v:DI 46) 0)
  >                 (ashift:SI (subreg:SI (reg/v:DI 44) 0)
  >                     (const_int 1)))
  >             (set (reg:SI 18 t)
  >                 (lt:SI (subreg:SI (reg/v:DI 44) 0)
  >                     (const_int 0)))
  >         ] ) -1 (nil)
  >     (nil))
  > 
  > Is this a reasonable rtx? I don't understand why you would have a parallel
  > shift with a compare, so this seems rather fishy to me.
There's nothing wrong with it if the machine supports this kind of
instruction.  I don't know what target you're using and thus I can't
hazard a guess as to whether or not this is a suitable instruction
for your machine.

  > It looks like the previous rtx is generated by the first scheduling pass;
  > here's the rtx before scheduling:
  > 
  > (insn 35 33 36 (parallel[
  >             (set (subreg:SI (reg/v:DI 46) 0)
  >                 (ashiftrt:SI (subreg:SI (reg/v:DI 44) 0)
  >                     (const_int 31)))
  >             (clobber (reg:SI 18 t))
  >         ] ) 68 {ashrsi2_31} (nil)
  >     (expr_list:REG_UNUSED (reg:SI 18 t)
  >         (nil)))
  > 
  > but after try_split() is called, the first rtx is generated...
This is certainly possible if the target has a define_spit which
isn't operating correctly.

jeff