(Class-) array finalization and initialization question

[Salvatore Filippone]

On Cray: this runs

  call ten_init(x_ten(::2, ::3))
!!$  call tee_init(x_tee(::2, ::3))
!!$  call tne_init(x_tne(::2, ::3))
  call tnn_init(x_tnn(::2, ::3))
!!$  call tae_init(x_tae(::2, ::3))
  call tan_init(x_tan(::2, ::3))
!!$  call tge_init(x_tge(::2, ::3))
  call tgn_init(x_tgn(::2, ::3))

invoking any one  of the commented subroutines makes the code segfault.
Salvatore

On Thu, Feb 19, 2015 at 1:00 PM, Andre Vehreschild <vehre@gmx.de> wrote:
> Hi Salvatore,
>
> thanks for the test. Can you narrow where the cray-compiled executable
> segfaults? May be by compiling with -g and running in a debugger/valgrind to
> get a line number?
>
> On compiling with GCC 5: My last pull is some days ago. And with that version it
> compiled just fine. Now updating to the most recent state and trying again. I
> remember there was some traffic on this list about pure/impure routines, may be
> this has corrected that issue. I will adapt the source soon.
>
> Regards,
>         Andre
>
> On Thu, 19 Feb 2015 12:43:22 +0100
> Salvatore Filippone <filippone.salvatore@gmail.com> wrote:
>
>> Compiling and running with Cray I get a segfault.
>> With GNU 5.0 it does not compil:
>>
>> [sfilippo@localhost Scaricati]$ gfortran -o fintest fintest.f08
>> fintest.f08:139:33:
>>
>>    elemental subroutine tae_init(x)
>>                                  1
>> Error: INTENT(OUT) argument 'x' of pure procedure 'tae_init' at (1)
>> may not be polymorphic
>>
>> On Thu, Feb 19, 2015 at 12:23 PM, Andre Vehreschild <vehre@gmx.de> wrote:
>> > Hi all,
>> >
>> > I have compiled a small test-program to catch all cases of this topic and
>> > check what other compilers do in these cases (see attachment).
>> >
>> > I am now looking for volunteers with access to third party fortran2008
>> > compilers to compile and run the attached program. Please post the full
>> > output and the compiler you used. When you needed to modify the test
>> > program, please attach the modified version, too, enabling me to analyze
>> > the output correctly.
>> >
>> > Thank you for all your help.
>> >
>> > Regards,
>> >         Andre
>> >
>> > On Wed, 18 Feb 2015 17:07:44 +0100
>> > Salvatore Filippone <filippone.salvatore@gmail.com> wrote:
>> >
>> >> Hmm.
>> >> I am sorry, you appear to be right, and the Cray compiler actually
>> >> agrees with you. I was too hasty :(
>> >>
>> >>
>> >> On Wed, Feb 18, 2015 at 5:03 PM, Andre Vehreschild <vehre@gmx.de> wrote:
>> >> > Hi Salvatore,
>> >> >
>> >> > thanks for the quick reply.
>> >> >
>> >> > The cited F2008 standard at the position given says, that any
>> >> > subcomponent provided with a default-initializer is default-initialized.
>> >> > IMHO this does conflict with what you tell me. Or do I misinterpret this
>> >> > fragment:
>> >> >
>> >> > "The INTENT (OUT) attribute for a nonpointer dummy argument specifies
>> >> > that the dummy argument becomes undefined on invocation of the
>> >> > procedure, except for any subcomponents that are default-initialized
>> >> > (4.5.4.6)." (F2008, 5.3.10, §3)
>> >> >
>> >> > and it means that the dummy arguments become undefined, besides all
>> >> > arguments that have subcomponents that are default-initialized don't
>> >> > become undefined. Those remain defined, but are not
>> >> > re-default-initialized? I don't hope the standard is to be interpreted
>> >> > like that. That would be quite unexpected. Which user of Fortran is to
>> >> > understand that, and what is the higher use of it?
>> >> >
>> >> > Regards,
>> >> >         Andre
>> >> >
>> >> > On Wed, 18 Feb 2015 16:05:34 +0100
>> >> > Salvatore Filippone <filippone.salvatore@gmail.com> wrote:
>> >> >
>> >> >> >Note the intent(out) here, which is the second crucial point and in
>> >> >> >combination with the call to init() in the main program:
>> >> >> >
>> >> >>  > type(t1), allocatable :: x(:,:)
>> >> >>   >allocate(t1 :: x(5,5))
>> >> >>   >x%i = 1
>> >> >>   >call init(x(::2, ::3))
>> >> >> >
>> >> >> >one gets the remarkable result, that now x%i is -13 for the entries
>> >> >> >selected by the strides. My question now is: why are those values -13
>> >> >> >and not 42 as I would expect from the default initializer? The array
>> >> >> >elements selected by the strides have been undefined when calling
>> >> >> >init() as of F2008 5.3.10 Â3 (first sentence) hence calling the
>> >> >> >finalizer. But from that same sentence I would expect the
>> >> >> >default-initializer to be set for the values instead.
>> >> >>
>> >> >> Because the default inizializer is called when you invoke ALLOCATE,
>> >> >> whereas the finalizer is invoked at the time you enter the INIT
>> >> >> routine since it has an INTENT(OUT) dummy argument.
>> >> >> Since within INIT you do not touch the X argument anymore, the output
>> >> >> is consistent with the rules.
>> >> >>
>> >> >> Saying it again, the default initializer is only invoked when you
>> >> >> create a new variable instance by an ALLOCATION, or (as in the
>> >> >> attached example) by using an automatic array of the correct type
>> >> >> module type_mod
>> >> >> type t1
>> >> >>     integer :: i = 42
>> >> >>   contains
>> >> >>     final :: fin
>> >> >>   end type t1
>> >> >> contains
>> >> >>   elemental subroutine fin(x)
>> >> >>     type(t1), intent(inout) :: x
>> >> >>     x%i = -13 * x%i
>> >> >>   end subroutine fin
>> >> >> end module type_mod
>> >> >>
>> >> >> module init_mod
>> >> >>   use type_mod
>> >> >> contains
>> >> >>   subroutine init(x)
>> >> >>     type(t1), intent(out) :: x(:,:)
>> >> >>     type(t1) :: a(size(x,1),size(x,2))
>> >> >>     x = a
>> >> >>   end subroutine init
>> >> >> end module init_mod
>> >> >>
>> >> >> program tryfin
>> >> >>   use init_mod
>> >> >>
>> >> >>
>> >> >>   type(t1), allocatable :: x(:,:)
>> >> >>   allocate(t1 :: x(5,5))
>> >> >>   x%i = 1
>> >> >>   call init(x(::2, ::3))
>> >> >>
>> >> >>   write(*,*) x%i
>> >> >> end program tryfin
>> >> >>
>> >> >>
>> >> >> which produces
>> >> >> [sfilippo@localhost PSBLAS_V3]$ ./tryfin
>> >> >>           42           1          42           1          42
>> >> >> 1           1           1           1           1           1
>> >> >>  1           1           1           1          42           1
>> >> >>  42           1          42           1           1           1
>> >> >>    1           1
>> >> >>
>> >> >>
>> >> >> because the initializer is called when you instantiate the local
>> >> >> variable A.
>> >> >>
>> >> >> Salvatore
>> >> >
>> >> >
>> >> > --
>> >> > Andre Vehreschild * Email: vehre ad gmx dot de
>> >
>> >
>> > --
>> > Andre Vehreschild * Email: vehre ad gmx dot de
>
>
> --
> Andre Vehreschild * Email: vehre ad gmx dot de