(Class-) array finalization and initialization question
Salvatore Filippone
filippone.salvatore@gmail.com
Fri Feb 20 08:01:00 GMT 2015
My gcc 5 is:
sfilippo@localhost NUMERICAL]$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/gnu/5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/opt/gnu/5.0.0
--enable-languages=c,c++,fortran
--with-gmp=/usr/local/travel/GCC/BUILDS/gmp
--with-mpfr=/usr/local/travel/GCC/BUILDS/mpfr
--with-mpc=/usr/local/travel/GCC/BUILDS/mpc
--with-cloog=/usr/local/travel/GCC/BUILDS/cloog
Thread model: posix
gcc version 5.0.0 20150218 (experimental) (GCC)
[sfilippo@localhost NUMERICAL]$ gfortran -c 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
As for the Cray runs, with commented out calls, it runs like this
sfilippo@hopper11:~/NUMERICAL> ./fintest
LIBDMAPP WARNING: Unable to open kgni version file
/sys/class/gemini/kgni0/version errno 2
ten_fin_counts: 0
tee_fin_counts: 0
tne_fin_counts: 0
tnn_fin_counts: 0
tae_fin_counts: 0
tan_fin_counts: 0
tge_scalar_fin_counts: 0
tge_array_fin_counts: 0
tgn_scalar_fin_counts: 0
tgn_array_fin_counts: 0
x_ten: 25*1
x_tee: 25*2
x_tne: 25*3
x_tnn: 25*4
x_tae: 25*5
x_tan: 25*6
x_tge: 25*7
x_tgn: 25*8
Note that I commmented only the CALL statements, not the definition of
the INIT routines.
Hope this helps
Salvatore
On Thu, Feb 19, 2015 at 6:37 PM, Andre Vehreschild <vehre@gmx.de> wrote:
> 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