Here is a complete example that we wrote illustrating the allocate
to achieve inheritance and polymorphism in our object oriented
at the time we wrote the book the Intel compiler
did not implement the feature.
The latest version of the Intel compiler (13.0.1) now
compiles and runs this example.
we needed additional switches over the default for
the following compilers. I've added the switches I can remember
in the list below.
ibm -qlanglvl=2003pure -qxlf2003=polymorphic
to get the object oriented ones to compile and run.
Hope this helps.
From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
Sent: 07 December 2012 19:13
To: [log in to unmask]
Subject: Re: Do derived-types with allocatable components go together with
thanks for your reply.
> I wonder whether you really want to use a function call instead of a
> subroutine call with passing the result as argument.
Indeed, using a subroutine instead does not cause any problems.
> What happens is:
> test_typ = ret_fct( 10 )
> The right-hand side is evaluated, then "test_typ" is automatically
> allocated and the right-hand side is assigned to "test_type" - and
> then the result variable of "ret_fct" is finalized.
This is exactly what I wanted to achieve. There is some reason why I
do not want to use a subroutine call instead. Later on, I'd like to
use that function to overload the structure constructor.
> The reason that it doesn't work with Intel is that their compiler
> hasn't enabled automatic (re)allocation on assignment enabled by
Eureka! How could I forget about that. In fact, with setting the
-assume lhs-realloc flag it works just fine.
> My guess is that the "mpif95" wrapper calls a different compiler /
> version than if you invoke "gfortran".
I already tried with a couple of versions: OpenMPI 1.4 and 1.6. The
wrapper script called one of gfortran 4.7.1, 4.7.2 and from trunk rev.
192192 . Independently of compiler, wrapper combination, the result is
a segmentation fault.
> FUNCTION ret_fct( sz ) RESULT( abcd )
> ftn-287 crayftn: WARNING RET_FCT, File = mpialloc.f90, Line = 23, Column =
> The result of function name "ABCD" in the function subprogram is
> not defined.
Actually, I have to admit not clearly understanding that warning. From
my point of view 'ABCD' is clearly defined. In my case, gfortran got
the -O0 and -g switches, so there should be no optimization, at all.
Well, maybe I rather replace the function by a subroutine call ...