- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - I'll pass these on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page