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

Is this allowed to be pure?

Mark_Lewy
Valued Contributor I
792 Views

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?

0 Kudos
1 Solution
Steven_L_Intel1
Employee
792 Views

I believe you are correct - I'll report this to the developers. Issue ID is DPD200363341. Thanks.

View solution in original post

0 Kudos
5 Replies
Steven_L_Intel1
Employee
793 Views

I believe you are correct - I'll report this to the developers. Issue ID is DPD200363341. Thanks.

0 Kudos
jimdempseyatthecove
Honored Contributor III
792 Views

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

0 Kudos
Steven_L_Intel1
Employee
792 Views

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.

0 Kudos
jimdempseyatthecove
Honored Contributor III
792 Views

>>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

0 Kudos
Steven_L_Intel1
Employee
792 Views

This has been fixed for the next major release.

0 Kudos
Reply