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

error #6995: BIND(C), PURE, ELEMENTAL characteristics of object and target must be same in a procedure pointer assignment.

AT
Beginner
742 Views

 

 

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

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
742 Views

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.

View solution in original post

0 Kudos
8 Replies
AT
Beginner
742 Views

te

0 Kudos
Steve_Lionel
Honored Contributor III
742 Views

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.

0 Kudos
AT
Beginner
742 Views

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 

 

 

 

0 Kudos
Steve_Lionel
Honored Contributor III
742 Views

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.

0 Kudos
AT
Beginner
742 Views

 

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


 


 

0 Kudos
Steve_Lionel
Honored Contributor III
742 Views

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.

0 Kudos
AT
Beginner
742 Views

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 .

0 Kudos
Steve_Lionel
Honored Contributor III
743 Views

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.

0 Kudos
Reply