From:  robert.corbett@sun.com
Newsgroups: comp.lang.fortran
Subject: Re: Fortran 90 modules suck for portability- why use them?
Date: Sun, 15 Jul 2007 18:01:36 -0700
Message-ID: <1184547696.851907.267770@22g2000hsm.googlegroups.com>

On Jul 13, 12:15 pm, henrikhols...@gmail.com wrote:
> Hi fellow Fortran users (old and new)!
>
> I am new to Fortran but not to programming in general. I started to
> program more seriously Fortran just a couple of months ago and now I
> have come up to a cross section where I need some help to understand
> the design of Fortran 90.
>
> I have seen some serious issues (yes, strong word) with Fortran 90
> modules. The binary compatibility  between different compilers
> - even on the same architecture - is zero. Also they create a
> terrible mess in the Make scripts. I just cannot understand why
> Fortran 90 thought there was a need to reinvent the wheel - and
> make a terrible work while doing so?

You are correct that modules made an already bad situation
regarding compatibility between codes compiled using different
compilers worse.  The lack of compatibility creates serious
problems for users.  A user who has purchased a library that
was compiled with one compiler cannot, in general, use that
library with codes compiled with another compiler.

C implementations tend not to have the same problems regarding
compatibility as Fortran.  The reason is not that the features
of C are more conducive to portablitity than Fortran.  They are,
but that is not the reason.  The reason is that, for each of the
major platforms, there is a well-defined C application binary
interface (ABI).

For years, I have toyed with the idea of writing a Fortran ABI.
The main reason I have not is that I doubt that any ABI I wrote
would be adopted.  I see no point in undertaking the effort to
write a Fortran ABI if it won't do any good.

> Let's look at the test module testmod.f90:
> MODULE TESTMOD
>     INTEGER :: X
> CONTAINS
>     SUBROUTINE COMPUTE
>     END SUBROUTINE
> END MODULE TESTMOD
>
> Between the three different compilers I have available I see the
> following difference in the object files:
>
> gfortran 4.2
> 00000000 T __testmod__compute
> 00000000 B __testmod__x
>
> Intel Fortran 9.1
> 00000000 T testmod._
> 00000002 T testmod_mp_compute_
> 00000004 C testmod_mp_x_

What linker name does Intel Fortran use for a subroutine
named testmod_mp_x?  Do they double up the low lines?

> Sun studio 12
> 00000000 T testmod.compute_
> 00000000 B testmod.x_
> 00000000 D testmod_

Sun's convention for generating linker names for contained
procedures was adapted, at the request of Sun's debugger team,
from the conventions used by Sun Pascal.

We made a mistake in the way Sun Fortran forms linker names.  The
prefixes should have matched the linker name of the outer scoping
unit.  In the example given, the first two linker names should
have been

     testmod_.compute_
     testmod_.x_

Sun's compiler includes an option that causes the trailing low line
to not be appended to the end of the linker name.  Except for the
blunder, it would have been possible to mix modules conpiled one
way and the other in the same program.  Of course, once the
compiler was released, it was too late to do anything about the
problem.

> Also the .mod file is different.

The problem used to be worse.  At least the convention of naming
the files .mod has largely caught on.  Sun resisted that convention
for some time, because our convention was in some ways better.
Nonetheless, user pressure forced us to conform to the .mod
convention.

One member of Sun's Fortran team has advocated extending our
compiler's code for reading module files to allow the compiler to
read module files generated by g95 and gfortran.  The GPL and
related issues of tainting have been enough to prevent his idea
from gaining any traction.

Bob Corbett