Re: Using user defined type in Fortan 77 subroutines

Hifi-Comp <wenbinyu.heaven@xxxxxxxxx> wrote:

TYPE (DN) FUNCTION DDOT(N,DX,INCX,DY,
+INCY)
USE TEST
C
C FORMS THE DOT PRODUCT OF TWO VECTORS.
C USES UNROLLED LOOPS FOR INCREMENTS EQUAL TO ONE.
C JACK DONGARRA, LINPACK, 3/11/78.
C
TYPE (DN) DX(*),DY(*),DTEMP
INTEGER I,INCX,INCY,IX,IY,M,MP1,N
60 DDOT = DTEMP
RETURN
END

DNAD.f90
MODULE TEST
TYPE,PUBLIC:: DN
REAL(8)::x
REAL(8)::xp
END TYPE DN
END MODULE TEST


Using CVF IDE on a PC, I can simply create a project containing these
two files. Both files can be compiled without any problem. Howeve, to
use gfortran in Linux system,
I do the following
gfortran -c DNAD.f90
DNAD.o and test.mod are generated.

Hower, when I compile blas.for using

gfortran -c blas.for

I got the following error messages:
In file blas.for:9

TYPE (DN) DX(*),DY(*),DTEMP
1
Error: Type name 'dn' at (1) is ambiguous
In file blas.for:11

60 DDOT = DTEMP
1
Error: Derived type 'dn' at (1) is being used before it is defined
In file blas.for:1

TYPE (DN) FUNCTION DDOT(N,DX,INCX,DY,
1
Error: The derived type 'ddot' at (1) is of type 'dn', which has not
been defined.

Doesn't look to me like this has anything at all to do with f77-related
issues, or for that matter with how you do the compilation. No wonder I
couldn't figure out what you were asking about. This is simply failure
of the code to compile and has nothing to do with it being originally
f77 or with any of the other issues that you mentioned.

Looks to me like the main problem is that you use the type DN prior to
the USE statement that makes it available. Apparently the CVF compiler
allows this, but gfortran does not.

To tell the truth, I forget whether the standard allows this case or
not. If it does allow it, then you have a bug report against gfortran.
I'll allow others to figure out whether or not such a bug report is
needed.

But my recommendation, regardless of whether the standard allows the
practice, is not to do it. It just asks for problems. If the standard
does allow it, then it is as a special-case exception to the general
rule. I know there are at least some such special-case exceptions, but I
have never bothered to memorize what cases they cover and what cases
they omit. I find it preferable to avoid their use.

Instead, I recommend taking the TYPE(DN) off of the function statement.
Replace it with a type declaration statement (after the USE) as in

type(dn) :: ddot

As I said, I don't recall whether the standard says that your original
code should work, but this change is "safer" anyway.

P.S. This is about example 42 billion of probably the most universal
advice on posting problem reports here. Don't try to describe the
problem. Odds are the description will be wrong anyway. Instead, show us
the problem. There is simply no way anyone could have figured this out
from the description in the original post. Some of us do occasionally
get flashes of vision in our crystal balls, but I don't think anyone has
a crystal ball that would have been up to that.

I'm not 100% sure that we have the problem completely solved yet. Some
of those error messages slightly puzzled me, but I'm hoping that they
were just fallout from the issue that I do see. In any case, I think we
can make progress from here.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: <ctype.h> toLower()
    ... > If it's a free standing implimentation, then the scope of the standard is ... I am talking about the compiled object code when I mean ... advantages of object code far outweigh source code in terms of portability. ... > you compile it with a hosted implimentation for that platform). ...
    (alt.comp.lang.learn.c-cpp)
  • Re: export
    ... > The standard mandated lots of things not demanded by the market, ... Only when you think of templates as functions. ... You don't compile them to object code, ... cannot make libraries of metafunctions and meta-object files with any ...
    (comp.lang.cpp)
  • Re: Why does this work? POSTPONE [Beginner]
    ... Mikail has explained how some implementations work, but there are other variations that also yield perfectly standard behavior. ... Some systems use a word by that name to compile literals, whereas others use LITERAL, another word, or even incorporate the literal in a machine instruction. ... That is not a very common thing to want to do in Forth, since conventionally Forth processes text to generate executable code. ... following a defining word by its name is natural and convenient. ...
    (comp.lang.forth)
  • Re: C++ Coding Standards
    ... In standard C is not possible to replace ... Compile cleanly at high warning levels. ... Always write internal #include guards. ...
    (comp.lang.c)
  • Re: getting env. variables in gfortran...
    ... of the libpxf standard. ... I doubt anyone actively working on gfortran ... library is a only a minor subset of the POSIX standard. ... new portability nightmares. ...
    (comp.lang.fortran)
Quantcast