(Class-) array finalization and initialization question

Andre Vehreschild vehre@gmx.de
Thu Feb 19 17:37:00 GMT 2015


Hi Salvatore,

thanks for testing. This means, that the cray compiler does not get along with
an elemental subroutine with intent(out) (indicated by the second e in the
typenames).

Could you send me the output of the program with the comments? This output
tells me, what the compiler does in the specific cases.

Odd is, that your gcc5 does not compile the test program. Can the compiler be
somewhat older? What system does (OS, CPU) does it run on? I updated my gcc5 at
noon and both the predecessor and the most recent trunk compiles the test
program fine. 

Any one with another brand of compiler (intel, pgf) available to give the
testprogram a try?

Regards,
	Andre


On Thu, 19 Feb 2015 15:37:19 +0100
Salvatore Filippone <filippone.salvatore@gmail.com> wrote:

> 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


-- 
Andre Vehreschild * Email: vehre ad gmx dot de 



More information about the Fortran mailing list