pgf90 Segmentation fault (core dumped)

Hello,

I am new in compiling a FORTRAN code by means of pgf90, the purpose to start using it is GPU utilization.

First, I’ve tried to compile a few simple programs which previously were compiled by means of gfortran and worked well.

I faced with the following problem. Compilation goes normal, however, the running of the program returns error. The first part of the program works correct, but when the execution comes to the specific place(I’ve identified it), I obtain: Segmentation fault (core dumped).

Corresponding “problem” part is as follows(the exact place is marked by !!!):

module fun_common
...

	abstract interface
		real(kind = 8) function fnr(x)
		real(kind = 8) :: x
		end function fnr
	end interface	

	contains
	....
		
	real(kind = real64) function VScreenedPot (phiIn, k1In,k2In)
		implicit none
	
		real(kind = real64) :: phiIn, k1In,k2In, kin
		
		kin=dsqrt(k1In**2 + k2In**2-2.d0*k1In*k2In*dcos(phiIn))				
			
		VScreenedPot=((2.d0*pi*el**2)/(epsilon0*BulcSizeData**2))*1.d0/(kin*(kin*rho0+1.d0))

	end function VScreenedPot
	
	real(kind = real64) function VAverage(k1In,k2In)
		implicit none
		real(kind = real64) :: k1In, k2In, inVal
		real(kind = real64) :: start_val, end_val
		integer :: n

		n=4000
		start_val=0.d0
		end_val=2.d0*pi
		inVal = 0.d0

		call trapezoid_integration(n,start_val,end_val,Vintegrand,inVal)

		VAverage=(1.d0/(2.d0*pi))*inVal

		contains			

		real(kind = real64) function Vintegrand(phiIn)
			implicit none
			real(kind = real64) :: phiIn
			Vintegrand=VScreenedPot(phiIn,k1In,k2In)

		end function Vintegrand

	end function VAverage

	....
	subroutine trapezoid_integration(n,start_val,end_val,integrand,integralf)
		implicit none
		integer :: n, i
		real(kind = real64) :: start_val, end_val
		real(kind = real64) :: integral, u, h, integralf
		procedure(fnr) :: integrand

		integral = 0.d0

		do i=0,n
			u = start_val+(end_val-start_val)*i/n
			if ((i.eq.0).or.(i.eq.n)) then
				!!!! HERE !!!!
				integral = integral+integrand(u) ! If I use, say, dsin, it works well.
			else
				integral = integral+(2.d0*integrand(u))
			end if
		end do

		h=(end_val-start_val)/n
		integralf = (h/2.d0)*integral

	end subroutine trapezoid_integration

This means that if I use some function as argument the program fails.

My system: GeForce RTX 2060, Ryzen 2700, CentOS Linux release 7.8.2003, PGI 19.10

Thank you in advance for any help!

p.s. kind=real64 is the same as kind=8

Hi Andrey K,

Are you able to provide a complete reproducing example so we can run the program? Unfortunately, I can’t tell what’s wrong given this snip-it.

While we don’t support all of F2008, we did add support for passing of internal procedures as arguments in the 18.4 release. While the feature has been there a few years, there could be a compiler problem with this particular code. But I’d need a reproducer to see if this is the case.

-Mat

Dear Mat,

Thank you for your quick response!

Honestly, I would prefer not to publish the full sources here. I did not find the form how to contact you directly. Therefore, if it is possible and appropriate for you, you can mail me: and I send you all the sources.

ps I hope this behavior does not contradict the philosophy of the comunity

No problem. Normally I’d have you send a note to PGI Customer Service at trs@pgroup.com and have them forward it to me, but I’ll contact you directly in this case. I’ll then update the forum once we have a resolution.

Note that I removed your email from the above post since this is a public forum.

-Mat

FYI, Andrey sent me the code an I was able to reproduce the error.

It appears to me to be a compiler issue so I’ve added a problem report, TPR #28648, and sent it to our engineers for further evaluation.

What appears to be happening is that when the internal procedure that’s passed as a reference is accessing the parents variables, in particular the arguments being passed into the parent, the code seg faults. Though I can work around the error if I copy the parent’s argument into a local variable in the parent and then use that new local variable in the internal procedure.

Thanks for the report,
Mat