Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
2 Views

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

Jump to solution

 

 

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

Accepted Solutions
Highlighted
Black Belt
2 Views

As far as I know, it is

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos
8 Replies
Highlighted
Beginner
2 Views

te

0 Kudos
Highlighted
Black Belt
2 Views

The compiler is now properly

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
2 Views

What I am doing is that I am

Jump to solution

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
Highlighted
Black Belt
2 Views

I don't know anything about

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
2 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
Highlighted
Black Belt
2 Views

Do you need to use the same

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
2 Views

Down the pipeline, once I

Jump to solution

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
Highlighted
Black Belt
3 Views

As far as I know, it is

Jump to solution

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.

Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran

View solution in original post

0 Kudos