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

Re: netCDF & f90 compiler - M6925

Barry,

>Date: Thu, 12 Jun 97 11:45 CDT 
>From: address@hidden (Barry Caplin)
>Organization: Numerical Algorithms Group (NAG)
>To: address@hidden
>Subject: Re: netCDF & f90 compiler - M6925 
>Keywords: 199706021417.IAA27579

In the above message, you wrote:

> > f90 compiler.  On his behalf, I'm taking this opportunity to contact you
> > personally.  Since Mauget is a NAG f90 client, I hope this is OK with
> > you.
>    Sure, no problem.

Great!

> > The problem that Mauget is experiencing stems from the NAG f90
> > compiler not supporting constructs like the following:
> > 
> >       integer*1 a(2)
> >       integer   b(2)
> > 
> >       call sub(a)
> >       call sub(b)
> > 
> > The above is conforming Fortran-77 (modulo the "integer*1" datatype
> > -- but I suspect the problem would occur even if "a" was "real").
>    Not only is this not standard conforming f77, but the * data types
> don't even exist in ansi/iso standard f77 (except for character*) !
> Now, most f77 compilers have the extension for int*2, but very few
> have int*1.

I agree that "integer*1" is a non-standard datatype.  This is why I
added the "modulo" caveat in my previous message.  Strictly conforming
code that might illustrate a similar problem would be the following:

     integer i(2)
     doubleprecision d(2)
     call sub(i)
     call sub(d)
     end

Does the NAG f90 compiler handle this?

>    In any case, how do you define the dummy argument in the declarations
> of subroutine sub?  Is it an equivalence?  That might work.  Actually, I
> just tried this with Sun f77 and it did work (defining the dummy arg to
> be simply integer), however, this is definitely not standard.

My understanding of the Fortran standards is that they do not require
that the called routine be written in Fortran.  In this particular
case, the called routine is written in C -- so there's no problem with
multiple datatypes -- but it could just as well have been written in
assembly or some other language.

The problem lies with the compilation of the calling routine --
independent of the called routine -- the calling routine won't compile.

>    According to the ansi/iso f77 standard, sec. 15.6.2.3, p. 15-10,
> "Actual Arguments for a Subroutine.  The actual arguments in a subroutine
> reference must agree in order, number, and type with the corresponding dummy
> arguments in the dummy argument list of the referenced subroutine."

I'm afraid I don't have a copy of the Fortran-77 standard.  What is the
equivalent in the Fortran-90 standard?  (See my next comment before
responding.)

> >  My reading of the Fortran-90 standard (I have a copy) indicates
> > that the above should be conforming Fortran-90 as well.

>    Also not the case.

Could you be more specific (i.e. where does the standard indicate that
this construct is non-conforming)?  The closest thing I could find was
section 12.3.2.4 "Implicit interface specification":

    In a scoping unit where the interface of a function is implicit, the
    type and type parameters of the function result are specified by
    implicit or explicit type specification of the function name.  The
    type, type parameters, and shape of dummy arguments of a procedure
    referenced from a scoping unit where the interface of the procedure
    is implicit must be such that the actual arguments are consistent
    with the characteristics of the dummy arguments.

I interpret the above as placing constraints on the dummy arguments
of the called routine if (and only if) the called routine is written
in Fortran-90.  I don't interpret it as placing any constraint on the
actual arguments in the calling routine.

Does NAG interpret this section differently?

>    There are other options including
> the use of optional arguments, or doing a trick with equivalences.  In any
> case this would involve some source code changes.

Unfortunately, due to circumstances beyond our control, that option is
unavailable to us.

>    The same code I tried above with the Sun f77 compiler, would not
> compile with NAG f90.  The NAG f90 is strictly standard compliant.
> This is both a feature and a curse!  NAG's business is portable code.
> This is why we try to adhere to standards wherever possible.

We also try to adhere to standards (we thought we did).

>    Here's another idea.  I don't know if you guys would want to
> rebuild netcdf with NAG f90.  If so, you can download free demo
> versions our f77->f90 converter and our f90 compiler for most unix
> machines from our web site.

Thanks.  I might try that for other reasons.  Unfortunately, I don't see
how it can help the current situation.

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