970611: building using NAG f90

Steve,

>Date: 11 Jun 1997 13:02:43 -0500 
>From: "Steve Mauget" <address@hidden>
>Organization: USDA
>To: "Steve E" <address@hidden>
>Subject: NAG Correspondence... 
>Keywords: 199706021417.IAA27579

In the above message, you wrote:

>      Here is the text of the e-mail I sent to NAG, and the two replys I've
> gotten so far.

Thanks for the info.

See my comment on their test code.

> *****************************************************************************
> Dear NAG Consultant:
> 
>      I am currently trying to install some share-ware data
> management software (netCDF common data format software:
> http://www.unidata.ucar.edu/ ...edu/packages/netcdf ) on our
> SGI Indigo2 on which your f90 compiler is also installed. When
> I invoke the test portion of the installation I get the error
> messages listed below. Below is just a sampling of these messages,
> but all the offending arguments to the subroutine calls all have
> one thing in common, which is that they are either integer or
> integer*2 variables. The lines right after the error messages are
> the type declarations for the variables that seem to be causing the
> problems. These same subroutines are called at other times with
> arguments of different type with no problem. The people who distribute
> netCDF seem to think its a problem with the compiler, but if that
> was the case I would guess that the problem would not be confined to
> subroutine arguments of only type integer. Given these circumstances
> what does the error message mean to you:
> 
> Error: ftest.f, line ****: Inconsistent datatype for arg * in call to ****
> 
> Is it possible that the netcdf and the f90 compiler are not agreeing
> some how on what constitutes valid integer and integer*2 variables?
> 
>                                               Just Wonderin,
>                                               Steve Mauget
> 
> 
> Error: ftest.f, line 2786: Inconsistent datatype for arg 4 in call to NCAGT
>             integer*2  shval(2)
>             call ncagt (outcdf, NCGLOBAL, attnam, shval, iret) 
> 
> 
> Error: ftest.f, line 6852: Inconsistent datatype for arg 6 in call to NCAPT
>             integer*2  svalidrg(2)
>             call ncapt (ncid, sid, 'validrange', NCSHORT, 2, 
>                +svalidrg, iret)
> 
> 
> Error: ftest.f, line 13560: Inconsistent datatype for arg 5 in call to NCVGT
>             integer*2  sarray(times)
>             call ncvgt (ncid, m, start, count, sarray, iret)
> 
> 
> Error: ftest.f, line 14933: Inconsistent datatype for arg 4 in call to NCVGT1
>             integer*2  svalue
>             call ncvgt1 (ncid, sid, sindx, svalue, iret)
> 
> 
> 
> Error: ftest.f, line 14945: Inconsistent structure for arg 3 in call to NCVGT1
>             integer findx(4)
>             call ncvgt1 (ncid, fid, findx, fvalue, iret)
> 
> 
> Error: ftest.f, line 16276: Inconsistent datatype for arg 5 in call to NCVPT
>             integer*2  sarray(times)
>             call ncvpt (ncid, sid, start, count, sarray, iret)
> 
> 
> Error: ftest.f, line 17623: Inconsistent datatype for arg 4 in call to NCVPT1
>             integer*2  svalue
>             call ncvpt1 (ncid, sid, sindx, svalue, iret)
> 
> 
> Error: ftest.f, line 18923: Inconsistent datatype for arg 4 in call to NCVGT1
>             integer*2  s
>             call ncvgt1(ncid, sid, ix, s, iret)
> 
> 1
> [f90 error termination]
> *** Error code 2 (bu21)
> *** Error code 1 (bu21)
> *** Error code 1 (bu21)
> 
> *************************************************************************
> 
> Hi Steve,
> > 
> > Is it possible that the netcdf and the f90 compiler are not agreeing
> > some how on what constitutes valid integer and integer*2 variables?
>    I don't think so.  Once again, I don't know anything about netcdf,
> but here is a short f77 routine that uses i*2 and i*4 and works fine
> with f90:
>       integer*2 i2
>       integer   i4
> 
>       external sub
> 
>       i2 = 5
>       i4 = 10
> 
>       write(*,*) 'i2 kind = ',kind(i2)
>       write(*,*) 'i4 kind = ',kind(i4)
>       call sub(i2,i4)
> 
>       end
> 
>       subroutine sub(i2,i4)
>       integer*2 i2
>       integer   i4
> 
>       write(*,*) 'in sub'
>       write(*,*) 'i2 kind = ',kind(i2)
>       write(*,*) 'i4 kind = ',kind(i4)
> 
>       return
>       end
> 
> > f90 -V t.f 
> NAGWare f90 compiler Version 2.2(325)
> Copyright 1990-1995 Numerical Algorithms Group Ltd., Oxford, U.K.
> f90com version is 2.2(325)
> Extension: t.f, line 1: Byte count on numeric data type
>            detected at *@2
> Extension: t.f, line 16: Byte count on numeric data type
>            detected at *@2
> [f90 continuing despite warning messages]
> > a.out
>  i2 kind =  2
>  i4 kind =  3
>  in sub
>  i2 kind =  2
>  i4 kind =  3
> 
>    The kind function is specific to f90, but the rest of the program is
> non-standard f77 (the integer* data specifier is NOT in the f77 or f90
> standard).
>    By the line numbers you gave you are clearly working with some huge code.
> I suggest you focus on one of the errors.  Make a copy of the code and
> delete everything that is not directly involved with that call.  Then see
> what happens.  You can send that to me also.  There is clearly a problem,
> but I don't know what it is.
> 
>    Barry

A more appropriate test would be to compile the following:

      integer*1 i1
      integer*2 i2
      integer   i4

      integer*1 i1a(2)
      integer*2 i2a(2)
      integer   i4a(2)

      external sub

      call sub(i1)
      call sub(i2)
      call sub(i4)

      call sub(i1a)
      call sub(i2a)
      call sub(i4a)

      end

Please let me know what you discover.

> 
> ************************************************************************
> 
> Hi Steve,
>   Do you have source for netcdf?  If so, is it possible to take a routine that
> is
> failing and pare it down to the minimum amount of code needed to cause an
> error?
>    You mention the install program as the source of the errors.  Is this a
> source code, a script, or some kind of makefile?  Perhaps you can execute
> it with sh -x to get more verbose info?  Also, if you can compile programs
> separately and they work, then maybe you can build this package by hand
> instead
> of using the install program/script?
> 
>    Barry
> 
> Barry Caplin        address@hidden        http://www.nag.com/
> Numerical Algorithms Group Response Center, USA    Technical Support
> phone: 630-971-2345
> fax  : 630-971-2346
> 
> ***********************************************************************************
> To which I replied:
> 
> Barry:
> 
>      The netcdf install process is guided by ( to me) a fairly involved
> makefile. These errors come from a makefile that invokes a fortran test
> program that basically goes through and tests every subroutine in the netcdf
> library. I'm not sure how I would build something like that by hand as the
> source code for these subroutines are not made available, just the netcdf
> object code library file (libnetcdf.a) On the other hand, if you folks want to
> play around with it, it is freely available over the net (
> ftp.unidata.ucar.edu/ub/netcdf/netcdf.tar.Z ). For what its worth I appear to
> have my own netcdf program working right now. Why my program will compile
> properly and their test programs will not I don't know.
> 
>                                                                               
>                                                              Steve M.

--------
Steve Emmerson   <address@hidden>