Replying to myself:
Please ignore the previous message "Compiler analysis question". The code has a
serious blunder in that it uses a function result as if it were a intent(inout)
subroutine argument. It seemed to work and I did not notice this until it crashed
during a different test.
Sorry,
Aleksandar

> Hello,
>
> I am still playing with array temporaries and aliasing tests and have
> come up with an example where the compiler seems to be smarter then me,
> and am confused about how it comes to the conclusion that no temporary
> is needed. Maybe some of the compiler experts can help me understand how
> the aliasing analysis goes in this case (sorry for the long
> code--questions are given as comments):
>
>   ! In order to use overloading of operator(+)
>   type allocatable_array
>      real, allocatable, dimension(:) :: array
>   end type allocatable_array
>   type pointer_array
>      real, pointer, dimension(:) :: array
>   end type pointer_array
>
>    interface operator(+)
>      module procedure AddAlloc
>      module procedure AddPtr
>   end interface
>
> where
>
>    function AddAlloc(b,c) result(a)
>       type(allocatable_array), intent(in) :: b,c
>       type(allocatable_array) :: a
>
>       a%array=b%array+c%array ! NO temporary--aliasing is forbidden by
> standard
>
>    end function AddAlloc
>
>    function AddPtr(b,c) result(a)
>       type(pointer_array), intent(in) :: b,c
>       type(pointer_array) :: a
>
>       a%array=b%array+c%array ! NO temporary--but is this just
> fortunate?
>       ! Can a%array be aliased with b%array or c%array?
>
>    end function AddPtr
>
> Now here are some tests with these "dynamic arrays" used inside a
> derived data-type, and an puzzling observation:
>
>   ! Here are four different data-types containing three "dynamic
> arrays":
>   type box_type_1
>     real, allocatable, dimension(:) :: a, b, c
>   end type box_type_1
>   type box_type_2
>     type(allocatable_array), pointer :: a, b, c
>   end type box_type_2
>   type box_type_3
>     real, pointer, dimension(:) :: a, b, c
>   end type box_type_3
>   type box_type_4
>     type(pointer_array) :: a, b, c
>   end type box_type_4
>
> Observe the results in the comments:
>
>   type(box_type_1) :: box_1
>   type(box_type_2) :: box_2
>   type(box_type_3) :: box_3
>   type(box_type_4) :: box_4
>
>    !...Allocate all arrays and pointers
>
>    box_1%a=box_1%b+box_1%c ! Requires no temporary--guaranteed by
> standard
>   ! (my compiler uses one, but this is a flaw)
>
>    box_2%a=box_2%b+box_2%c ! No temporary with overloading of (+) above
>    box_2%a%array=box_2%b%array+box_2%c%array ! Temporary *is* used
>        ! but only if previous line is commented out, otherwise compiler
> is smart to see non-aliasing
>        ! which was a pleasantly suprising result.
>    ! Here is a puzzling result. Why does even this not cause a temporary
> allocation
>    ! with above lines commented out. Is this guaranteed by the standard,
>
>    ! or is this a compiler analysis valid only for this program ?
>    ! (since this was all one file, global analysis might be at play)
>    box_2%b=box_2%b+box_2%c! Still no temporary--why?
>
>    box_3%a=box_3%b+box_3%c ! A temporary is used since aliasing may
> occur
>
>    ! Exactly the same as for box type 3 is observed for box type 4:
>    box_4%a=box_4%b+box_4%c ! No temporary
>    box_4%a%array=box_4%b%array+box_4%c%array ! A temporary is used if no
> previous line
>    box_4%b=box_4%b+box_4%c ! Still no temporary--why?
>
> Thanks,
> Aleksandar
>
> --
> __________________________________
> Aleksandar Donev
> Complex Materials Theory Group (http://cherrypit.princeton.edu/)
> Princeton Materials Institute & Program in Applied and Computational Mathematics
> @ Princeton University
> Address:
>    419 Bowen Hall, 70 Prospect Avenue
>    Princeton University
>    Princeton, NJ 08540-5211
> E-mail: [log in to unmask]
> WWW: http://atom.princeton.edu/donev
> Phone: (609) 258-2775
> Fax: (609) 258-6878
> __________________________________