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

Re: 19990105: Netcdf on Linux

>To: russ
>cc: address@hidden, address@hidden
>From: address@hidden (Bill McKie)
>Subject: Re: 19990105: Netcdf on Linux
>Organization: Earth Sciences Division, Raytheon ITSS at NASA Ames Research 
>Center
>Keywords: 199901051951.MAA10394 199812140236.TAA07774 Portland Group pgcc

Hi Bill,

> Thanks very much for sending the new cfortran.h for use with pgi
> compilers.  (I was sent a copy of your response to Geoff Vallis because
> I had previously emailed about a pgi compiler problem.)  This is for
> netcdf v3.4, and I believe you sent this on 5-Jan-1999.
> 
> I have finally had some time to try this new cfortran.h file with a
> build of netcdf v3.4 on our Linux system (Redhat v5.2) using the pgi C
> and Fortran-90 compilers (and excluding the C++ interface by setting
> CXX to null).  The pgi compilers version is 1.7-6.3, as shown on the
> following report.
> 
> I am seeing a successful build of the libnetcdf.a library plus ncdump
> and ncgen utilities.  And some of the "make test" tests show successful
> execution.  But I am also seeing some fatal problems in the "make test"
> phase of the install, e.g. in the ncvarget and nf_test tests.
> 
> I captured a somewhat full report of my netcdf v3.4 build attempt, and
> will append it below.  It is probably more detail than you need to find
> the problem, but I thought something in this report might help you find
> what is going wrong, and/or will be of interest to the netcdf development
> group.
> 
> We are hoping to soon use netcdf as the standard i/o interface in a new
> parallel version of a cloud and microphysics model written in
> Fortran-90 and running under Linux with pgi compilers, and are
> naturally interested in seeing netcdf v3.4 build and test stably on our
> system.

The success that Geoff Vallis reported using the Portland Group pgf90
compiler was with /usr/bin/cc on his Linux system rather than with
pgcc.  We haven't heard from anyone else who has tried the combination
of pgcc and pgf90 to build netCDF 3.4.  The output you sent may reveal
a problem with pgcc:

 ...
> pgcc -V
> pgcc-warning-No files to process
> 
> pgcc Rel 1.7-6.3
> Copyright 1989-1998, The Portland Group, Inc. All Rights Reserved.
 ...
> Making `all' in directory /ua/sys.misc/netcdf.distrib/netcdf-3.4/src/libsrc
> 
> make[2]: Entering directory 
> `/ua/sys.misc/netcdf.distrib/netcdf-3.4/src/libsrc'
> pgcc -c  -I.  -DpgiFortran attr.c
> pgcc -c  -I.  -DpgiFortran dim.c
> pgcc -c  -I.  -DpgiFortran error.c
> pgcc -c  -I.  -DpgiFortran -DVERSION=`cat ../VERSION` libvers.c
> pgcc -c  -I.  -DpgiFortran nc.c
> pgcc -c  -I.  -DpgiFortran ncio.c
> PGC-W-0142-Assignment to const object not allowed (./posixio.c: 462)
> PGC-W-0142-Assignment to const object not allowed (./posixio.c: 842)
> PGC/x86 Linux/x86 Rel 1.7-6.3: compilation completed with warnings
> pgcc -c  -I.  -DpgiFortran ncx.c
> pgcc -c  -I.  -DpgiFortran putget.c
> PGC-W-0142-Assignment to const object not allowed (putget.c: 367)
 ...

The above warning messages seem to indicate a compiler bug, which may
also be causing the nctest problem you are later seeing, if the
compiler is not just issuing the warnings but also failing to perform
the specified assignments.  In each case, there is a declaration
something like

        void **const vpp;

followed later by an assignment such as

        *vpp = ...

that is not an assignment to a const object (that would be **vpp) but
rather to what the const object points to (*vpp), which is not const.

 ...
> *** Testing ncvarget1 ...     ok ***
> *** Testing ncvarput ...      ok ***
> *** Testing ncvarget ...      *** test_slabs: ncvarget got wrong value for 
> point
> *** test_slabs: ncvarget got wrong value for vector

These errors don't seem to occur with the /usr/bin/cc compiler.  We
don't have access to the pgcc compiler here so can't test whether a
compiler error is really the cause of the problem, but you might be
able to construct a simple test case that works with /usr/bin/cc but
fails with pgcc.  This would help to either confirm the bug, or at
least determine if the compiler generates code that performs the
assignment even after issuing the bogus warning.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu