- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
the following error is something I begun to get with the new IFORT version (18.0.1)..
It says error #6995: BIND(C), PURE, ELEMENTAL characteristics of object and target must be same in a procedure pointer assignment.
I think I know the reason. I have an abstract interface with pure subroutine.
The subroutine I am calling this interface is not pure, but that is only because I am including mkl_rci.fi which cannot take pure routines. Before I did not have a problems, so is there a way to solve this problem with the new version?
thank you
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I know, it is simply improved error checking in the compiler. This happens a lot in new releases. Not only do I not know of other workarounds, but such could cause problems elsewhere in your program if the compiler assumed you were following the standard's rules where you weren't.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
te
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The compiler is now properly enforcing a restriction specified in the standard.
7.2.2.4 (Procedure pointer assignment) in F2008 says:
"If the pointer object has an explicit interface, its characteristics shall be the same as the pointer target except that the pointer target may be pure even if the pointer object is not pure and the pointer target may be an elemental intrinsic procedure even if the pointer object is not elemental."
Then, 12.3.1 says:
"The characteristics of a procedure are the classification of the procedure as a function or subroutine, whether it is pure, whether it is elemental, whether it has the BIND attribute, the characteristics of its dummy arguments, and the characteristics of its result value if it is a function."
I don't know what you mean by "cannot take pure routines". A pure routine can be use anywhere a non-pure routine could be.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What I am doing is that I am pointing to a subroutine which does not include the pure attribute.
The pointer is declared as for a procedure "procedure(solver), pointer :: ptr => NULL()"
The "solver" procedure contains pure subroutines.
So does this mean that I must point "ptr" to a pure subroutine?
I am pointing ptr to pure subroutines like ptr => solver1, where solver1 is a pure subroutine, and that works!
But, when saying ptr => solver2, where solver2 is not "pure" subroutine, it gives me the problem
That did not appear before but now it does. And I cannot declare solver2 as pure because it includes the mkl_rci library
Can you see where my error emerge please?
Thanks for helping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I don't know anything about mkl_rci, Where is abstract interface solver declared? If it's your own, just remove the pure attribute from the procedure argument, since you're going to be violating that rule otherwise.
It would be helpful if you could show a small but complete example that demonstrates the problem and that isn't dependent on having MKL installed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay I will try to show a simple example of this. The problem by removing pure is that I need to remove many many pure elsewhere, because that abstract interface is used heavily throughout the code, and I am using it to do a few "forall" and "do concurrent" loops. This was also done for performance purposes, and it will be a bit sad if this is the only solution, namely to remove the pure.
Notice that this shows you the exact skeleton of the code. But the processes are not shown to keep it simple.
So the thing is that I have numerous different types of solver1 routines (named differently and not shown here), but this specific one includes the mkl_rci, hence, I have not been declaring it as pure. Till this point it has not been an issue for me, until I updated the fortran compiler. Now it gives me the error mentioned in the title and indicating the line number which refers to where I point ptr to solver1.
!-----Module 1 example----------! module mod_examp1 implicit none abstract interface intf_examp1 pure subroutine sub_examp1(dum, func1) implicit none real, intent(in) :: dum interface pure subroutine sub_sub_examp1(du1,du2) implicit none real, intent(in)::du1,du2 end subroutine sub_sub_examp1 end interface end subroutine sub_examp1 end interface procedure(intf_examp1), pointer :: pnt1 => NULL() contains subroutine solver1(i, func1,du1,du2) !!!! Pure or not pure??? include 'mkl_rci.fi' real, intent(in)::du1,du2 interface pure subroutine sub_sub_examp1(du1,du2) implicit none real, intent(in)::du1,du2 end subroutine sub_sub_examp1 end interface call func1(du1,du2) end subroutine end module !!!!!!!!!!!!!!! !-----Module 2 example----------! module mod_examp2 use mod_examp1 implicit none subroutine call_solver pnt1 = > solver1 !!!! That gives the problem when I don't have pure in front for solver1 routine end subroutine end module
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you need to use the same abstract interface in all these locations? Maybe you can have two interfaces, one pure and one not. You can point to pure procedures with either one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Down the pipeline, once I have pointed to a procedure, I am using some forall and do concurrent. So, if I had to split into two abstract interfaces it would require more effort than just that. Because, I would have to also split those forall and do concurrent to incorporate if the procedure is not pure.
Is the error mentioned is a direct consequence of the more strict checking of the new Fortran Compiler? I just want to make sure that, and there is no workaround else than actually doing it how you suggested.
Thanks a lot for your help .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As far as I know, it is simply improved error checking in the compiler. This happens a lot in new releases. Not only do I not know of other workarounds, but such could cause problems elsewhere in your program if the compiler assumed you were following the standard's rules where you weren't.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page