(Class-) array finalization and initialization question

Thu Feb 19 12:00:00 GMT 2015

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 