- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The following code is rejected by ifort/ifx although it is valid F2008+:
subroutine s (ptr1, ptr2)
real, pointer :: ptr1(:), ptr2(:,:)
print *, associated (ptr1,ptr2)
print *, associated (ptr2,ptr1)
end
I get:
ifort_associated_target.f90(3): error #6376: The shapes of the arguments do not conform. [ASSOCIATED]
print *, associated (ptr1,ptr2)
----------------------------^
ifort_associated_target.f90(4): error #6376: The shapes of the arguments do not conform. [ASSOCIATED]
print *, associated (ptr2,ptr1)
----------------------------^
compilation aborted for ifort_associated_target.f90 (code 1)
See e.g. F2018:16.9.16 for details on the expected result.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry. I disagree, and so does NAG Fortran:
D:\Projects>nagfor -c t.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7108
Evaluation trial version of NAG Fortran Compiler Release 7.1(Hanzomon) Build 7108
Error: t.f90, line 3: Arguments to intrinsic ASSOCIATED have different type/kind/rank/char-length
Error: t.f90, line 4: Arguments to intrinsic ASSOCIATED have different type/kind/rank/char-length
What you're missing is this:
TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
We then go to 10.2.2 which says (emphasis mine):
C1019 (R1033) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target shall be the same.
So... not valid Fortran 2018.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sorry. I disagree, and so does NAG Fortran:
D:\Projects>nagfor -c t.f90
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7108
Evaluation trial version of NAG Fortran Compiler Release 7.1(Hanzomon) Build 7108
Error: t.f90, line 3: Arguments to intrinsic ASSOCIATED have different type/kind/rank/char-length
Error: t.f90, line 4: Arguments to intrinsic ASSOCIATED have different type/kind/rank/char-length
What you're missing is this:
TARGET (optional) shall be allowable as the data-target or proc-target in a pointer assignment statement (10.2.2) in which POINTER is data-pointer-object or proc-pointer-object.
We then go to 10.2.2 which says (emphasis mine):
C1019 (R1033) If bounds-remapping-list is not specified, the ranks of data-pointer-object and data-target shall be the same.
So... not valid Fortran 2018.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For whatever it's worth, I too felt the code in the original post did not conform, at least as per the standard as it stands now.
However it does feel like the practitioners will benefit if there is another look at the ASSOCIATED intrinsic with the standard committee and whether something can be improved considering the pointer remapping to rank-one array extension starting Fortran 2003 (see below) and later with simply contiguous targets in 2008:
integer, target :: a(4)
integer, pointer :: b(:,:)
a = [ 1, 2, 3, 4 ]
b(1:2,1:2) => a !<-- conforms
print *, b
!print *, associated(b,a) !<-- doesn't conform now but can it not!!!?
end
Under the circumstances, there is some room for improvement with the ASSOCIATED intrinsic as two whole objects can be pointer associated and not have the same shape.
Is this something you can follow up with the committee for consideration in Fortran 202Y?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@FortranFan , I'm uncertain what the benefit of that relaxation would be. I note that ASSOCIATED currently requires that the pointer and target, if arrays, have the same shape in order to return .TRUE. - this would be violated if the ranks differ. What practical use would such a change be? If you can make a good case for it, write a J3 paper and it can get submitted for review.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
From what I can see, the verbiage re: "have the same shape" in the ASSOCIATED intrinsic dates back to Fortran 95 when pointer assignment called for rank conformance. My impression is there is likely benefit for users if the ASSOCIATED intrinsic can be used in scenarios that correspond to those permitted with the pointer assignment extensions in Fortran 2003 and 2008. If I see more support of this view from the users generally, I will submit a brief paper.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IMHO, I agree with FortranFan for this reason. As an example, it is not and unusual programming practice to reference a rank-2 (or higher) array as a rank-1 array. While one could use (loc(a) == loc(b)), the use of associated would be equally (presumed to be) valid.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can use pointer remapping to create a rank 1 pointer to a rank 2 array. I do note that the definition of DEALLOCATE would support deallocating a pointer of different shape as long as " the allocated object is an array the pointer shall be an array whose elements are the same as those of the allocated object in array element order.", so I could see it making sense for ASSOCIATED to use the same logic. (NB - Intel Fortran, unless they fixed this, can complain in cases where you are deallocating the whole array, but the pointer was assigned in a way that the compiler didn't track that.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am starting to understand now, but am still wondering why the standard then did not explicitly state that the ranks of pointer and target must agree.
A slight variation of the original testcase - now using F2018 assumed-rank for the POINTER argument;
subroutine s (p, ptr1, ptr2)
real, pointer :: p(..)
real, pointer :: ptr1(:), ptr2(:,:)
! print *, associated (p,ptr1) ! ICE w/ ifort
! print *, associated (p,ptr2) ! Rejected
select rank (p)
rank (1)
print *, associated (p,ptr1) ! OK
rank (2)
print *, associated (p,ptr2) ! OK
end select
end
The non-commented part of the example compiles OK.
Uncommenting the line
! print *, associated (p,ptr1) ! ICE w/ ifort
produces an internal compiler error with ifort 2021.6. The other commented line would simply be rejected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The standard does say so explicitly - I quoted the text. But as with much of the standard, things are said in one place only and other things refer to that place. You sometimes have to go a few levels deep to find all the words you need, but it didn't take me long to find it this time. The key here is that the pointer and target arguments must be valid for pointer assignment, which they are not in your example.
ifort should not be allowing an assumed-rank pointer in this context.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is the way engineers work. You only show something once on a drawing so if you change it, you do not have to hunt for all the changes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am still confused (or maybe confusing) about what is said about the TARGET argument and about the POINTER argument.
I do not see any relevant constraints in F2018:16.9.3 paragraph 3 for the POINTER argument. I see there more text about what is admissible for TARGET, and one could read the reference to 10.2.2 just in this way.
Furthermore, with rank remapping, the "data-pointer-object" excludes the bounds-remapping-list. Of course, an object such as p(1:10,1:2), which might be admissible under the right circumstances as lhs in a rank-remapping, cannot be a pointer.
Metcalf/Reid/Cohen (fortran 95/2003 explained) state on p.161: "If target is present, it must have the same ... rank as pointer". I cannot find this text in the Fortran 2003 standard, so this is likely an interpretation of the text.
By the way: the Cray compiler seems to be more permissive, it accepts different ranks for pointer and target, and allows for assumed-rank for pointer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a nice set of examples in Chapter 10 page 251 of Guide to 2013 programming, but it simply says that associated returns are false if p1 and p2 are not the same, in a roundabout way.
Clearly, the example given above is false, the only argument is whether you pick it up at compile time or runtime.
Maybe nobody thought about it much, often we assume it is obvious.
--------------------------------------------------------------------------------------
By the way: the Cray compiler seems to be more permissive, it accepts different ranks for pointer and target, and allows for assumed-rank for pointer.
But it just going to tell you it is false. It has to as they are not aliases of the same thing. So what is the point?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Not sure what you are talking about ("Guide to 2013")??? AFAICT there is no Fortran 2013.
Nevertheless, there is a difference between rejecting code at compile time for some "legal" reason - or not so legal - and just returning .false. at runtime.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Springer Verlag, A guide to Fortran 2003 programming - W S Brainerd. An excellent book.
If the compiler passed your associated statement, and you use it in a do loop
do while (associated p1 p2) -- it can never be true and so never exit.
If someone has p1 in module 6 and p2 in module 7, maybe you will not know that p1 is 1d and p2 is 2d, so you want a compile error.
As for the sample I noted, the compile does not know that cosh(x) >= cos(x) so we loop forever.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I was taking Physics 101 at ANU in 1975. ANU is a very hard school, I struggled. We had a student in the class that would argue with the professor, this is basic Newtonian-type physics.
Professor says one day, it is obvious, student says it is not.
Professor leaves and then comes back with 20 books, looks at them for 15 minutes, stands up and says it is and goes on.
My Professorial friend gets very upset if I say "it is obvious or self-evident". Really angry.
We are in one of those arguments. But there is no professor, just equals.
--------------------------------------------------------------------------------------------------------------------------------------------
Second story:
1937 or thereabouts, a student is taking advanced stat class, comes in late, sees what he thinks is the homework on the board, and writes it down.
Sees the professor a week or so later and says this was really hard and gave two answer sets. prof looks and says you attempted the unsolved problems, do not be late for class.
6 months go by, Professor gets a paper to read, it is one of the solutions to be published in an academic journal, he remembers and digs out the solution, identical. The student gets PhD for the two solutions and his name is on the paper.
The student ends up as a famous stat guy who did I believe stellar work in WW2.
----------------------------------------------------------------------------------------------------------------------------------------------
Put the fault down to the tyranny of knowledge.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I still say that was you I saw tossing a shopping trolley into Sullivans Creek at ANU.<G>
Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
An Ursie would never throw it into the creek, we respect the environment. We would stick it in another hall.
The average Ursie was not quite normal, I agree.
They teach well at ANU, but mark very hard.
Windows 12 will be another flop.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ahhh, wouldn't it be more appropriate that you were pushing one of your drunk classmates in a shopping trolley into Sullivans Creek at ANU?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
LOL, These stories are best left for the beer hall, I am not sure our august friends are ready for Australian humour in the raw.
This is what happens when friends thrash a problem to death, we take humour in the situation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You know, it is possible to ride a shopping trolley down Black Mountain and crash into Sullivans Creek while you are under the influence.
Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Doc (not an Intel employee or contractor)
[Maybe Windows 12 will be better]
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page