Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28381 Discussions

Parameterized derived type and array-valued function returning component data: strange run-time behavior

FortranFan
Honored Contributor II
293 Views

Another strange one with parameterized derived types: the following code compiles with no errors or warnings, but I can't understand the run-time behavior.  With Release configuration, the array-valued function only returns the elements per the default length.  However with Debug configuration, it appears the run-time hangs up (is the function is trying to return an array of infinite (or very large) size?).  I think the code is ok.

module m

   implicit none

   private

   type, public :: t(n)
      integer, len :: n = 1
      integer :: m_x(n)
   end type t

   public :: x

contains

   function x(this) result(retval)

      type(t(*)), intent(in) :: this
      !..
      integer(kind=kind(this%m_x)) :: retval(size(this%m_x))

      retval = this%m_x

      return

   end function x

end module m

program p

   use m, only : t, x

   type(t) :: foo

   print *, " foo%x = ", x(foo)

   stop

end program p

 

The Release configuration returns only the first element based on the default component length of 1 in the PDT:

  foo%x =  0
Press any key to continue . . .

 

But the Debug configuration seems to return an infinite-sized array.

0 Kudos
8 Replies
FortranFan
Honored Contributor II
293 Views

For whatever it's worth, a type-bound procedure for the array-valued function for the code in the original post results in the same behavior.  Perhaps Intel would be kind to add this to the test case for the tracking incident too.

module m

   implicit none

   private

   type, public :: t(n)
      private
      integer, len :: n = 1
      integer :: m_x(n)
   contains
      procedure, pass(this), public :: x => get_t_x
   end type t

contains

   function get_t_x(this) result(retval)

      class(t(*)), intent(in) :: this
      !..
      integer(kind=kind(this%m_x)) :: retval(size(this%m_x))

      retval = this%m_x

      return

   end function get_t_x

end module m

program p

   use m, only : t

   type(t(2)) :: foo

   print *, " foo%x = ", foo%x()

   stop

end program p

 

0 Kudos
Steven_L_Intel1
Employee
293 Views

Thanks - I'll pass these on.

0 Kudos
FortranFan
Honored Contributor II
293 Views

Thanks Steve.

I just realized I'd a typo at line 34 in the original post (oh, it'll be so nice if one could edit the original posts too!):

Please replace line 34 with the following (i.e., a length parameter that is something other than the default):

   type(t(n=2)) :: foo

 

0 Kudos
Steven_L_Intel1
Employee
293 Views

Which compiler version are you using? I can't duplicate the error of an "infinite sized array". Maybe you need to tell me the exact compiler options in use as well.

What I see for the first example is that if bounds checking is on, the assignment in function x gets an inappropriate bounds error. We already have a bug filed on that. Otherwise, the size of the array is properly 1 and it all seems to work.

What you have here is an "assumed type parameter", so when you pass foo from the main program, declared using the default length parameter of 1, that's what gets used for the dummy argument in routine x. Other than the bounds error, it seems to work ok for me.

The second example works the same as the first for me (in 15.0.2 - it doesn't compile in 15.0.0.)

0 Kudos
FortranFan
Honored Contributor II
293 Views

Thanks, Steve, for following up on this.  Please see Quote #4; I'd a typo in my original post.  Can you please retry with this change suggested in Quote #4?

Fyi, I'm using compiler version: Intel(R) Visual Fortran Compiler XE 15.0.2.179 [Intel(R) 64]

My current compiler options for the Debug configuration are

/nologo /debug:full /Od /D_NDEBUG /DWIN32 /DWIN64 /standard-semantics /Qdiag-error-limit:200
/stand:f08 /Qdiag-disable:7025 /warn:all /debug-parameters:all /iface:mixed_str_len_arg
/module:"Debug\x64\\" /object:"Debug\x64\\" /Fd"Debug\x64\p.pdb" /traceback /libs:static
/threads /dbglibs /c

With the above, I get a stack overflow error:

forrtl: severe (170): Program Exception - stack overflow
Image              PC                Routine            Line        Source

p.exe              000000013FB5DFD7  Unknown               Unknown  Unknown
p.exe              000000013FAD13EC  MAIN__                      7  p.f90
p.exe              000000013FB5D8EE  Unknown               Unknown  Unknown
p.exe              000000013FB5E0DC  Unknown               Unknown  Unknown
p.exe              000000013FB5E21E  Unknown               Unknown  Unknown
kernel32.dll       00000000772359ED  Unknown               Unknown  Unknown
ntdll.dll          000000007736BA01  Unknown               Unknown  Unknown
Press any key to continue . . .

 

I just realized I'd /heap-arrays0 option included when I submitted the original post.  With that option, I got the behavior that feels like a "hang-up".  Hope this helps.  If not , please let me know and I can e-mail you a zip of all the files including the Visual Studio solution and project files.

0 Kudos
Steven_L_Intel1
Employee
293 Views

Ah - it was the x64 I was missing. It seems to work ok for Win32.  Escalated as issue DPD200367091.

By the way, I'm interested in how you're planning on using PDTs. I remarked to the standards committee members that we had several customers trying them out, and they wanted to know "what for". There has been a rather long-held belief that PDTs aren't all that useful.

0 Kudos
FortranFan
Honored Contributor II
293 Views

Steve Lionel (Intel) wrote:

Ah - it was the x64 I was missing. It seems to work ok for Win32.  Escalated as issue DPD200367091.

By the way, I'm interested in how you're planning on using PDTs. I remarked to the standards committee members that we had several customers trying them out, and they wanted to know "what for". There has been a rather long-held belief that PDTs aren't all that useful.

Thanks Steve for submitting the tracking incident.

Re: your question on PDTs, I think IanH's comments in this topic (https://software.intel.com/en-us/forums/topic/542336) summarize nicely many of our motivations for using PDTs, especially what he says in Quote #12.   One can say the solutions we're currently offering to our consumers are very close to his PositionAlloc example, but the typical use cases by our customers are such we can be in PositionLen situation i.e., most of the data dimensions of objects are fixed states and one often does not need the flexibility offered by allocatable objects.  As mentioned by IanH, "length type parameters are just awesome."   So we're considering a rewrite of some of our code to transition from "PositionAlloc" to "PositionLen".  Note if PDTs had become available much earlier in the Fortran 2003 implementation cycle in Intel Fortran, then we would have started considering it for our code design much sooner and a lot of our code would have been developed using PDTs in the first place, especially with use of the length parameter.  

In addition, one other area where we're looking PDTs is to use kind parameters in the implementation of "abstract calculus" (example reference: Scientific Software Design book by Rouson et al. you mention in your Dr Fortran blog) in some of our core numerical libraries with both double precision (real64 and c_double from iso_fortran_env, iso_c_binding intrinsics) and quadruple precision (real132 from  iso_fortran_env) arithmetic in mind.  We hope to start investigating  how we might benefit from quadruple precision computations in certain "numerically sensitive" sections of our simulations without having to rewrite much code.  Albeit this is in very early stages and there are a lot of compiler improvements we're waiting for, but we're excited at the prospect of using kind parameter facility too.

So the belief that PDTs are not all that useful is incorrect.  Once robust implementations of PDTs become widespread in compilers, it can become very useful and if the standard can be further improved to facilitate generic programming (e.g., not requiring include files to handle kind parameter scenarios or being able to specify some limits on the type parameters, etc), PDTs can become even more powerful.  So I feel the standard-bearers should be looking to further improve this feature rather than leaving it as-is.

 

0 Kudos
Steven_L_Intel1
Employee
293 Views

The bug reported here has been fixed for a release later this year (I don't think it will go into a 15.0 update.)

0 Kudos
Reply