[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
970611: building using NAG f90
- Subject: 970611: building using NAG f90
- Date: Wed, 11 Jun 97 12:46:52 -0600
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>