[Patch, fortran] PR38863 - WHERE with multiple elemental defined assignments gives wrong answer

[Daniel Kraft]

Paul Richard Thomas wrote:
>  integer :: x(10)
>   call foo (x, 10)
> contains
>   subroutine foo (x, n10)
>     integer :: n10
>     integer :: x(n10)
>     x = x (1:10)
>   end subroutine
> end
> 
> This produces a temporary without the patch because the full array ref
> is not recognised to be the same as the explicit range because the
> array is automatic.  Of course, the solution is easy - check that one
> of the bounds and the stride is the same for the array and the
> reference.
> 
> I have no feeling for whether or not this is such an extreme corner
> case as to be useless.  However, the patch fixes the PR:-)
> 
> Bootstrapped and regtested on FC9/x86_64 - OK for 4.5?

Ok.

Just a few comments:

+	  if (!full_ref->u.ar.as
+	      || !full_ref->u.ar.as->lower[i]
+	      || !full_ref->u.ar.as->upper[i]
+	      || gfc_dep_compare_expr (full_ref->u.ar.as->lower[i],
+				       full_ref->u.ar.as->upper[i])
+	      || !ref->u.ar.start[i]
+	      || gfc_dep_compare_expr (ref->u.ar.start[i],
+				       full_ref->u.ar.as->lower[i]))
+	    return false;
+	  else
+	    continue;

I personally don't put "else" after return in the other branch and would 
just put the "continue" after the if.  But that's obviously just a 
personal style ;)  (Although I've seen Eclipse produce a warning about 
these constructs in Java.)

And another thing:  This removes an unneeded temporary for the case in 
the PR, which is obviously a good thing; however, what's *if* the 
temporary would in any case be needed?  I wonder whether the code would 
still be expected to work; this seems much the same as my MVBITS INOUT 
dependency thing...  So maybe the temporary (if one is needed) should 
also be initialized correctly.

Thanks, Daniel