- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the following example, I get a run-time exception "forrtl: sever (408): fort (7): Attempt to use pointer OUTP when it is not associated with a target" upon the call to the subroutine test. This happens when the run time check "Check for Null Pointers and Allocatable Array References" is turned on.
In my opinion, this is wrong as OUTP is actually an allocatable and not a pointer. Also the dummy argument is allocatable and intent (out). I believe that the call with the unallocated variable is legal (it works without the runtime check) and should not be detected as an error by the runtime checker.
This error is not limited to character allocatables but seems to occur for allocatable arrays as well. I also believe that this use should be legal even without intent (out) as long as the subroutine does not try to access the allocatable before it is actually allocated.
This issue occurs both with IVF 11.1.065 and IVF 2011.0.055
regards,
Thomas
In my opinion, this is wrong as OUTP is actually an allocatable and not a pointer. Also the dummy argument is allocatable and intent (out). I believe that the call with the unallocated variable is legal (it works without the runtime check) and should not be detected as an error by the runtime checker.
This error is not limited to character allocatables but seems to occur for allocatable arrays as well. I also believe that this use should be legal even without intent (out) as long as the subroutine does not try to access the allocatable before it is actually allocated.
This issue occurs both with IVF 11.1.065 and IVF 2011.0.055
regards,
Thomas
[fortran] program Console1 implicit none character(:), allocatable :: outp call test( outp ) write(*,*) outp contains subroutine test( chr ) character(:), allocatable, intent(out) :: chr chr = 'abc' end subroutine end program Console1[/fortran]
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thomas,
Thanks for bringing this to our attention. I have escalated this as issue DPD200161453. I was unable to reproduce a problem with "normal" allocatable arrays - remember that you have to use /assume:realloc_lhs to get the implicit allocation on assignment of non-character allocatables.
Thanks for bringing this to our attention. I have escalated this as issue DPD200161453. I was unable to reproduce a problem with "normal" allocatable arrays - remember that you have to use /assume:realloc_lhs to get the implicit allocation on assignment of non-character allocatables.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Steve,
thanks for escalating this issue.
As for "normal" allocatable arrays, it does happen in our code.However,I just tried it in the simple code andfailed to reproduce it. The allocatable arrays where it happens for useare fields in a base type that is extendend. The types and subroutinesare spread out across several modules, so it might be related to another issue. I will try to get a simple reproducer for this case.
regards,
Thomas
thanks for escalating this issue.
As for "normal" allocatable arrays, it does happen in our code.However,I just tried it in the simple code andfailed to reproduce it. The allocatable arrays where it happens for useare fields in a base type that is extendend. The types and subroutinesare spread out across several modules, so it might be related to another issue. I will try to get a simple reproducer for this case.
regards,
Thomas
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This was fixed in 12.0 Update 1.
![](/skins/images/C4F7392A5C68ACA60290C9576F107044/responsive_peak/images/icon_anonymous_message.png)
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page