- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Consider the attached program.
In 14.0.1.139 I get the following error for line 231:
error #7145: This object must not be used as the pointer-object or target of a pointer-assignment-stmt in a PURE procedure or an internal procedure contained in a PURE procedure. [UH_LIST] D:\source\VS Projects\IsThisPure\IsThisPure\IsThisPure.f90 231
However, 15.0.0.108 compiles this without errors.
I'm inclined to think that 14.0.1.139 is correct in rejecting this, following my interpretation of section 6.10 of Metcalf, Reid & Cohen, Modern Fortran Explained (further rules iv)). Is this correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you are correct - I'll report this to the developers. Issue ID is DPD200363341. Thanks.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I believe you are correct - I'll report this to the developers. Issue ID is DPD200363341. Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Could you summarize why this would be in error?
The function does not modify anything external to the function - no side effects.
The statement in question makes an instantaneous copy of the uh_list pointer, then traverses the list without modifying it.
While it may be true in a multi-threaded context that the list may change by way of different thread during the search, the same can be said if the function were not attributed as pure.
As an additional observation, in a multi-threaded context the array rain(:) could be in the state of flux, including reallocation left hand side, and therefor the reasoning behind the invalidation of => in pure function should apply to pure functions referencing dummy array.
And taking that by extension all referenced arguments for that matter, because the referenced argument could be modified by other thread during run of the pure function.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The standard says:
30 C1283 In a pure subprogram any designator with a base object that is in common or accessed by host or use
31 association, is a dummy argument with the INTENT (IN) attribute, is a coindexed object, or an object
32 that is storage associated with any such variable, shall not be used
...
34 (2) as the data-target in a pointer-assignment-stmt ,
UH_LIST is host-associated and therefore is not allowed as a data-target in pointer assignment. This presumably is to prevent you from circumventing the PURE restrictions using a local pointer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>UH_LIST is host-associated and therefore is not allowed as a data-target in pointer assignment. This presumably is to prevent you from circumventing the PURE restrictions using a local pointer.
Ok, let's reuse or repurpose existing syntax.... Consider in this example of:
type(uh), pointer, intent(in) :: current
Before pointing out that current is a local pointer as opposed to a dummy argument, the rational is avoid adding intent(readonly). If the language would add intent(readonly), then use of intent(readonly) would be preferred.
The purpose of the extension is to permit non-modifiable list walking in pure functions. Thusly attributed, removes the reasoning behind 34(2).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This has been fixed for the next major release.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page