pr25569

[Jeffrey A Law]

This fixes pr25569.

Basically it's possible for biv_p to return true, but
iv_analyze_result may be unable to analyze the biv.  While it's
desirable for iv_analyze_result to handle everything for which
biv_p returns true, according to Zdenek fixing that is going to
be nontrivial.

In the mean time it is safe to give up splitting variables
for which biv_p returns true, but iv_analyze_result returns false.

Bootstrapped and regression tested i686-pc-linux-gnu and I verified
the patch fixes the ICE on a ppc64 cross compiler.


-------------- next part --------------
	* loop-unroll.c (analyze_iv_to_split_insn): Handle 
	iv_analyze_result returning false.

Index: gcc/loop-unroll.c
===================================================================
*** gcc/loop-unroll.c	(revision 112242)
--- gcc/loop-unroll.c	(working copy)
*************** analyze_iv_to_split_insn (rtx insn)
*** 1670,1676 ****
      return NULL;
  
    ok = iv_analyze_result (insn, dest, &iv);
!   gcc_assert (ok);
  
    if (iv.step == const0_rtx
        || iv.mode != iv.extend_mode)
--- 1670,1686 ----
      return NULL;
  
    ok = iv_analyze_result (insn, dest, &iv);
! 
!   /* This used to be an assert under the assumption that if biv_p returns
!      true that iv_analyze_result must also return true.  However, that
!      assumption is not strictly correct as evidenced by pr25569.
! 
!      Returning NULL when iv_analyze_result returns false is safe and
!      avoids the problems in pr25569 until the iv_analyze_* routines
!      can be fixed, which is apparently hard and time consuming
!      according to their author.  */
!   if (! ok)
!     return NULL;
  
    if (iv.step == const0_rtx
        || iv.mode != iv.extend_mode)