[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: possible bug in pg 5.1 f90 compiler?

Steven Nakamoto <address@hidden> writes:

> This is a bug in the 5.1 compiler which we have fixed; we will
> soon have a new version of 5.1 (5.1-5) available from our webpage.
> For now, you can download tje 5.1-5 patch:
> 
> ftp://ftp.pgroup.com/x86/linux86-patches/linux86.tar.gz
> 
> Best regards,
> scn
> 
> 
> 
> address@hidden wrote:
> > Hello,
> > I work at Unidata on a popular scientific software package called
> > netCDF.
> > We have supported PG compilers for some time, but there is suddenly a
> > problem with version 5.1. The problem has to do with passing an F90
> > array section to a C function.
> > This problem did not occur with previous versions of PG compilers.
> > I've isolated the problem in the code below, and demonstrated that
> > this problem doesn't exist on the Sun or IBM F90 compilers (which we
> > also support).
> > If you could please try the code and tell me if you think this is a
> > PG
> > bug, or a mistake on our part, I can pass it on to the many users who
> > have been trying to compile netCDF with PG compilers.
> > Thanks,
> > Ed Hartnett
> > address@hidden
> > Unidata
> > Problem with Portland Group FORTRAN Compiler:
> > The netcdf 3.5.0 F90 tests fail on Portland Group's 5.1 F90 compiler,
> > but succeed on Sun's F90, IBM's F90 compiler, and others. These F90
> > tests have succeeded for previous versions of Portland Group's Fortran
> > compiler.
> > The problem turns out to be passing an array section as a function
> > parameter, and then passing that on to a C function. For PG the C
> > function does not get a pointer to the beginning of the array
> > section. Instead it gets a pointer to the beginning of the array, as
> > if it had not been sectioned.
> > The following short C and F90 programs illustrate the problem.
> > testit.c:
> > extern int nf_put_vars_real1_(  const float *A6 ) {   printf("test
> > array recv A6: %f\n", *A6);
> >   return 0; }
> > n1.f90:
> > program n1
> >   implicit none
> > interface
> >    function test_array_pass(values)
> >      real, dimension(:, :), intent( in) :: values
> >      integer :: test_array_pass
> >    end function test_array_pass
> > end interface
> >   integer :: res, counter
> >   real, dimension(4, 3, 2) :: pressure
> >   pressure = 949. + real(reshape( (/ (counter, counter = 1, 3 * 4 *
> > 2) /),  &
> >        (/ 4, 3, 2 /) ) )
> >   print *, "pressure:", pressure
> >   res = test_array_pass(pressure(:,:,2))
> > end program n1
> > function test_array_pass(values)
> >   real, dimension(:, :), intent( in) :: values
> >   integer :: test_array_pass
> >     print *, "test_array_pass got:", values
> >   test_array_pass = nf_put_vars_real1( values)
> >   end function test_array_pass
> > The C function nf_put_vars_real1 simply prints the first value of the
> > array it receives.
> > The F90 program fills a rank 3 array (pressure), prints it, and then
> > calles f0 function test_array_pass, passing in a (2D) section of the
> > pressure array, specifically the second half of the pressure array.
> > The function test_array_pass prints the array it got, and then calls
> > the C funtion nf_put_vars_real1, passing in the array.
> > On Sun, the function nf_put_vars_real1 shows that it receives an
> > array
> > starting with 962, as expected (i.e. it received a pointer to the
> > second half of the pressure array):
> > uname -a
> > SunOS laraine.unidata.ucar.edu 5.6 Generic_105181-38 sun4u sparc 
> > SUNW,Ultra-2
> > laraine.unidata.ucar.edu% c89 -c testit.c
> > laraine.unidata.ucar.edu% f90 -o n1 n1.f90 testit.o
> > laraine.unidata.ucar.edu% ./n1
> >  pressure: 950.0 951.0 952.0 953.0 954.0 955.0 956.0 957.0 958.0 959.0 960.0
> >  961.0 962.0 963.0 964.0 965.0 966.0 967.0 968.0 969.0 970.0 971.0 972.0 
> > 973.0
> >  test_array_pass got: 962.0 963.0 964.0 965.0 966.0 967.0 968.0 969.0 970.0 
> > 971.0
> >  972.0 973.0
> > test array recv A6: 962.000000
> > I've also run this test code on a AIX system, which produced the
> > correct answer (I had to remove the trailing _ in the C function name
> > in testit.c to comply with AIX C calling conventions).:
> > % uname -a
> > AIX gale 3 4 001330614C00
> > % xlc -c testit.c
> > % xlf90 -o n1 -qsuffix=f=f90 n1.f90 testit.o
> > ** n1   === End of Compilation 1 ===
> > ** test_array_pass   === End of Compilation 2 ===
> > 1501-510  Compilation successful for file n1.f90.
> > % ./n1
> >  pressure: 950.0000000 951.0000000 952.0000000 953.0000000 954.0000000 
> > 955.0000000 956.0000000 957.0000000 958.0000000 959.0000000 960.0000000 
> > 961.0000000 962.0000000 963.0000000 964.0000000 965.0000000 966.0000000 
> > 967.0000000 968.0000000 969.0000000 970.0000000 971.0000000 972.0000000 
> > 973.0000000
> >  test_array_pass got: 962.0000000 963.0000000 964.0000000 965.0000000 
> > 966.0000000 967.0000000 968.0000000 969.0000000 970.0000000 971.0000000 
> > 972.0000000 973.0000000
> > test array recv A6: 962.000000
> > But using the PG compiler, the C function prints 950, showing that it
> > is ignoring the f90 array section, and is pointing to the beginning,
> > not the second half, of the pressure array:
> > uname -a
> > Linux sunshine.unidata.ucar.edu 2.4.18-14smp #1 SMP Wed Sep 4 12:34:47 EDT 
> > 2002 i686 i686 i386 GNU/Linux
> > [ed@sunshine f90]$ c89 -c testit.c
> > [ed@sunshine f90]$ pgf90 -o n1 n1.f90 testit.o
> > n1.f90:
> > [ed@sunshine f90]$ ./n1
> >  pressure:    950.0000        951.0000        952.0000
> > 953.0000         954.0000        955.0000        956.0000
> > 957.0000         958.0000        959.0000        960.0000
> > 961.0000         962.0000        963.0000        964.0000
> > 965.0000         966.0000        967.0000        968.0000
> > 969.0000         970.0000        971.0000        972.0000
> > 973.0000     test_array_pass got:    962.0000        963.0000
> > 964.0000         965.0000        966.0000        967.0000
> > 968.0000         969.0000        970.0000        971.0000
> > 972.0000         973.0000    test array recv A6: 950.000000
> > I also tried using the portland group c compiler, pgcc, with the same
> > result.
> > I've read the Inter-Language Calling section of the PGI Users Guide,
> > and I think I'm in accordance with the rules.
> >