Problem with recent fixes in loop_iterations ?

Problem with recent fixes in loop_iterations ?

[Olivier Hainque]

Hello,

Hoping you would be able to help with a problem we face :)

Trying to bootstrap Ada on hpux with our internal GNAT tree leads to
SEGV from within loop_iterations. Basically, we get to

 /* If there are multiple conditionalized loop exit tests, they may jump
     back to differing CODE_LABELs.  */
  if (loop->top && loop->cont)
    {
      rtx temp = PREV_INSN (last_loop_insn);

      do
	{
	  if (GET_CODE (temp) == JUMP_INSN
	      /* Previous unrolling may have generated new insns not covered
		 by the uid_luid array.  */
	      && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop
       
 with a temp looking like the following :

 (jump_insn 5407 5406 5408 (addr_vec:DI[ 
            (label_ref:SI 5389)
            ...

 GET_CODE (temp) is indeed JUMP_INSN, but the associated JUMP_LABEL is NULL
 and INSN_UID dereferences it.

 Is having this kind of insn here something expected never to happen ... or
 should the test be refined, or ... ?

 Thank you very much in advance for your help,

 Kind Regards,

 Olivier Hainque
 --
 hainque@act-europe.fr

Re: Problem with recent fixes in loop_iterations ?

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:26:41PM +0100, Olivier Hainque wrote:
>  Is having this kind of insn here something expected never to happen ... or
>  should the test be refined, or ... ?

The test must be refined a good deal to deal with a switch statement.
Probably you should notice the ADDR_VEC | ADDR_DIFF_VEC and give up.


r~

Re: Problem with recent fixes in loop_iterations ?

[Olivier Hainque]

Richard Henderson <rth@redhat.com> writes:
> The test must be refined a good deal to deal with a switch statement.
> Probably you should notice the ADDR_VEC | ADDR_DIFF_VEC and give up.

 This part of the compiler is not very familiar to me. By give up, you mean
 returning 0, or would something like below be appropriate ? In any case,
 I'll prepare a properly formed submission.

 Thanks for your help,

 Kind Regards,

 Olivier

*** unroll.c    2001/11/27 22:09:09     1.149
--- unroll.c    2001/11/29 09:32:44
*************** loop_iterations (loop)
*** 3529,3534 ****
--- 3529,3536 ----
        do
        {
          if (GET_CODE (temp) == JUMP_INSN
+             /* Avoid analyzing jumps not related to the loop.  */
+             && JUMP_LABEL (temp) != 0
              /* Previous unrolling may have generated new insns not covered
                 by the uid_luid array.  */
              && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop



 

Re: Problem with recent fixes in loop_iterations ?

[Richard Henderson]

On Thu, Nov 29, 2001 at 10:35:22AM +0100, Olivier Hainque wrote:
>  This part of the compiler is not very familiar to me. By give up, you mean
>  returning 0...

Yes.


r~

Re: Problem with recent fixes in loop_iterations ?

[Richard Henderson]

On Thu, Nov 29, 2001 at 10:35:22AM +0100, Olivier Hainque wrote:
>  This part of the compiler is not very familiar to me. By give up, you mean
>  returning 0...

Yes.


r~

Re: Problem with recent fixes in loop_iterations ?

[Olivier Hainque]

Richard Henderson <rth@redhat.com> writes:
> The test must be refined a good deal to deal with a switch statement.
> Probably you should notice the ADDR_VEC | ADDR_DIFF_VEC and give up.

 This part of the compiler is not very familiar to me. By give up, you mean
 returning 0, or would something like below be appropriate ? In any case,
 I'll prepare a properly formed submission.

 Thanks for your help,

 Kind Regards,

 Olivier

*** unroll.c    2001/11/27 22:09:09     1.149
--- unroll.c    2001/11/29 09:32:44
*************** loop_iterations (loop)
*** 3529,3534 ****
--- 3529,3536 ----
        do
        {
          if (GET_CODE (temp) == JUMP_INSN
+             /* Avoid analyzing jumps not related to the loop.  */
+             && JUMP_LABEL (temp) != 0
              /* Previous unrolling may have generated new insns not covered
                 by the uid_luid array.  */
              && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop



 

Re: Problem with recent fixes in loop_iterations ?

[Richard Henderson]

On Tue, Nov 27, 2001 at 06:26:41PM +0100, Olivier Hainque wrote:
>  Is having this kind of insn here something expected never to happen ... or
>  should the test be refined, or ... ?

The test must be refined a good deal to deal with a switch statement.
Probably you should notice the ADDR_VEC | ADDR_DIFF_VEC and give up.


r~

Problem with recent fixes in loop_iterations ?

[Olivier Hainque]

Hello,

Hoping you would be able to help with a problem we face :)

Trying to bootstrap Ada on hpux with our internal GNAT tree leads to
SEGV from within loop_iterations. Basically, we get to

 /* If there are multiple conditionalized loop exit tests, they may jump
     back to differing CODE_LABELs.  */
  if (loop->top && loop->cont)
    {
      rtx temp = PREV_INSN (last_loop_insn);

      do
	{
	  if (GET_CODE (temp) == JUMP_INSN
	      /* Previous unrolling may have generated new insns not covered
		 by the uid_luid array.  */
	      && INSN_UID (JUMP_LABEL (temp)) < max_uid_for_loop
       
 with a temp looking like the following :

 (jump_insn 5407 5406 5408 (addr_vec:DI[ 
            (label_ref:SI 5389)
            ...

 GET_CODE (temp) is indeed JUMP_INSN, but the associated JUMP_LABEL is NULL
 and INSN_UID dereferences it.

 Is having this kind of insn here something expected never to happen ... or
 should the test be refined, or ... ?

 Thank you very much in advance for your help,

 Kind Regards,

 Olivier Hainque
 --
 hainque@act-europe.fr