Re: forall_3.f90

[Paul Brook <paul at codesourcery dot com>]

On Saturday 07 February 2004 7:52 am, Canqun Yang wrote:
> I have tested the patch both on IA32 and IA64 Liunx. On
> IA32, all testcase passed, but on IA64, specifics.f90
> still can not be passed.
<snip>
> Below is the wrong code segment extracted from
> forall_3.f90.t03.orginal.
> The while loop does not get the proper element number
> (num.63) for the
> temporary due to the inner_size (T.62) evaluated too
> early.
<snip>

You analysis of the problem is correct, however your solution is not.
An expression may only be used after its pre-code has been executed, and 
before its post-code has been executed. The pre- and post- trees may also 
depend on the index variable. Hence you need to move the whole calculation 
inside the inner loop, not just the resulting expression.

Consider the following case:

! Not complete/self contained, but sufficient to generate tree dumps.
subroutine evil_forall(c)
  implicit none
  type t
    logical valid
    integer :: s
    integer, dimension(:), pointer :: p
    character(5) :: q
  end type
  type (t), dimension (5) :: v
  integer i
  character(len=5) :: d
  character(len=*) :: c

  forall (i=1:5)
    v(i)%p(1:len_trim(v(i)%q // c)) = v(6-i)%p(1:len_trim(v(6-i)%q // c))
  end forall

end subroutine

Note that this exposes annother (unrelated) bug. The temporary used in the 
call to len_trim is never freed. I suspect this is a bug in the loop 
scalarizer when loop->array_parameter = 1, and is not specific to forall 
statements. The same bug can be seen in the following code:

call foo(v(1)%p(1:len_trim(v(i)%q // c)))

Paul