PGI User Forum
 SearchSearch   MemberlistMemberlist     RegisterRegister   ProfileProfile    Log inLog in 

CUDA-x86.

Run-time error when compiling with PGI, but not with Intel

 
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling
View previous topic :: View next topic  
Author Message
lwhatley



Joined: 07 Aug 2008
Posts: 2

PostPosted: Thu May 31, 2012 8:44 am    Post subject: Run-time error when compiling with PGI, but not with Intel Reply with quote

Hello,

Our site has a user with a fortran code (included below) that compiles fine with pgf90 (PGI), gfortran (GNU), and ifort (Intel). When executed however, only the version compiled with ifort completes successfully. Here is the error received when running the pgf90 version:

$ pgf90 -r8 cylindrical.f90 -o cylindrical.exe
$ ./cylindrical.exe
allocate arrays
Open grid files...
write grid file...
PGFIO/stdio: No such file or directory
PGFIO-F-/unformatted write/unit=120/error code returned by host stdio - 2.
File name = grid3dg.ggFine unformatted, stream access record = 0
In source file cylindrical.f90, at line number 57

FWIW the version compiled with gfortran segfaults, rather than providing the 4 lines of error messages like the pgf90 version provides.

This can be reproduced on multiple systems using anything from PGI 10.9 to PGI 11.10.

Any clues as to what's going on would be greatly appreciated. Our site has multiple PGI licenses, but an email sent to trs@pgroup.com has not elicited a response.

Thanks in advance!
-Lee


Here is the code in question:
------------------------------------------------
program hexahedronvol


implicit none


real::r
real::pi=3.141592653589793
integer::i,j,k,L,nxg,nyg,nzg
integer::nx,ny,nz,ni,nj,nk
real::aa,rr,phi,x0,y0

real,allocatable,dimension(:,:,:)::xx
!real,allocatable,dimension(:,:,:)::yy
real,allocatable,dimension(:,:,:)::zz



nx=1280
ny=896
nz=1920



nxg=nx
nyg=ny
nzg=nz


r=1.0

print*,"allocate arrays"
!-----------------------------------------------------
allocate(xx(1:nxg+1,1:1,1:nzg+1)); xx = 0.
!allocate(yy(1:nxg+1,1:1,1:nzg+1)); yy = 0.
allocate(zz(1:nxg+1,1:1,1:nzg+1)); zz = 0.

print*,"Open grid files..."
!---------------------------------------------------------

!---just for bump case
! open(120,file='bumpEtrdFF.grd',form='formatted')
! read(120,*) L
! read(120,*) nk,ni,nj
! read(120,*) (((xx(i,j,k),k=1,nk),i=1,ni),j=1,nj)
! read(120,*) (((aa, k=1,nk),i=1,ni),j=1,nj)
! read(120,*) (((zz(i,j,k),k=1,nk),i=1,ni),j=1,nj)
! close(120)
!---------------------------------------------------------



print*,"write grid file..."
!---------------------------------------------------------
open(120,file='grid3dg.ggFine',form='unformatted',access='stream')
write(120) nx+2,ny+2,nz+2
write(120) (((xx(i,1,k),i=1,nx+2),j=1,ny+2),k=1,nz+2) &
, ((((j-1.)*1.015625e-3,i=1,nx+2),j=1,ny+2),k=1,nz+2) &
, (((zz(i,1,k),i=1,nx+2),j=1,ny+2),k=1,nz+2)
close(120)

!---------------------------------------------------------




write(*,'(f18.16)') 2.3
end program
------------------------------------------------
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5871
Location: The Portland Group Inc.

PostPosted: Fri Jun 01, 2012 8:43 am    Post subject: Reply with quote

Hi lwhatley,

I finally had to send this off to one of our compiler engineers to look at. I seems to me that we're hitting an internal limit since the program only fails when the record size is around 8GB.

So the work around is to reduce the size of ny.

A couple of side notes. Is the "+2" in the write statement correct? This will cause out-of-bounds access since xx and zz are allocated with "+1", not "+2".

Second, if the user plans on using ny to size the second dimension, have them add the flag "-Mlarge_arrays" since they will be larger then 2GB.

- Mat
Back to top
View user's profile
lwhatley



Joined: 07 Aug 2008
Posts: 2

PostPosted: Fri Jun 01, 2012 9:08 am    Post subject: Reply with quote

mkcolg wrote:
I seems to me that we're hitting an internal limit since the program only fails when the record size is around 8GB.


Hi Mat,

Thanks for the response! When you say an "internal limit", do you mean a limit within the compiler, or some OS ulimit?

I have passed your response on to the user, and will let you know if your suggestions make a difference.

Thanks!
-Lee
Back to top
View user's profile
mkcolg



Joined: 30 Jun 2004
Posts: 5871
Location: The Portland Group Inc.

PostPosted: Fri Jun 01, 2012 9:29 am    Post subject: Reply with quote

Quote:
do you mean a limit within the compiler, or some OS ulimit?
Compiler but this is just a guess.
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    PGI User Forum Forum Index -> Programming and Compiling All times are GMT - 7 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © phpBB Group