Fortran 90 modules suck for portability- why use them? - Fortran

Hello Henrik,

henrikholst80 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.

Name mangling issues are a natural consequence of the additional
conceptual power (e.g., object based programming, encapsulation)
provided by modules. C++ has the same issues here, although there
may be more efforts to keep compatibility here (also due to g++
having been around for a long time!). Also note that even in Fortran
77 there were limits to binary compatibility (I/O).

> Also they create a terrible mess
> in the Make scripts.

There are scripts which can generate Make dependencies automagically
for you.

> I just cannot understand why Fortran 90 thought
> there was a need to reinvent the wheel - and make a terrible work
> while doing so?
>
> 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_
>
> Sun studio 12
> 00000000 T testmod.compute_
> 00000000 B testmod.x_
> 00000000 D testmod_
>
> Also the .mod file is different. <sarcasm>The new Fortran 2003
> standard talks about C integration. How about to start with Fortran <-
>> Fortran integration? </sarcasm>
>
> This means that you cannot compile a library with say gfortran and use
> it in any other compiler.
>
> If you avoid using Fortran modules you can get something that is
> binary compatible and usable between the three compilers I have
> available and have also tested with. I have [1] a small example of how
> to write "module code" without using modules. It boils down to using
> INCLUDE instead. There are some negativisms with not using MODULES as
> well but not as many.

For large scale and object based programming or library design, using "include"
will not do the job. Note in particular that
* distinctive types are generated per include, as opposed to modules.
This makes e.g. passing objects of a type to an external subroutine impossible.
* encapsulation features are *only* available for modules

>
>
> Leading researchers is using Fortran 95 [2] with modules I guess I
> just have to bend over and recognize that this is broken but nobody
> but me seems to care about it. Also, if you look at the BLAS95
> proposal routines, you see lot's of dangerous code. You see unsafe
> EXTERN keywords. I would though out modules and replace it with type
> checking any day of the week (Do not confuse modules with
> interfaces.).
>
> I think Fortran 90 has lot's of nice features which I think is
> essential to a modern programming language. I know I don't have to
> follow everyone else and use MODULES. I don't even have to use Fortran
> 90. But since so many are choosing to use modules and seems fine with
> that - where did you dispose of the bodies of those who questioned it?
>
> Thanks for your comments. I would very very much like to hear what you
> have to say about these things.
>
> [1] http://na37.nada.kth.se/mediawiki/in..._the_seventies
> [2] http://www.cs.umd.edu/~stewart/matran/Matran.html
>
> Cheers,
> --
> Henrik Holst, Sweden
> http://www.csc.kth.se/~holst/contact.shtml
>
Regards

Reinhold

In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de> wrote:

> C++ has the same issues here, although there
>may be more efforts to keep compatibility here

Well, there are a lot of system libraries for C++, so for example on
Linux, gcc and Intel and PathScale all have the same mangling. You
can't have a viable compiler otherwise.

In the Fortran77 world, gfortran isn't even g77 compatible. So
PathsScale, which was g77 compatible for name mangling (but not the
I/O library), got burned when gfortran decided to mangle names
differently by default. Oh well.

And for the Fortran 9X world, well, there was obvious choice to
imitate.

-- g

Greg Lindahl wrote:
> In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de> wrote:
>
>> C++ has the same issues here, although there
>> may be more efforts to keep compatibility here
>
> Well, there are a lot of system libraries for C++, so for example on
> Linux, gcc and Intel and PathScale all have the same mangling. You
> can't have a viable compiler otherwise.
>
> In the Fortran77 world, gfortran isn't even g77 compatible. So
> PathsScale, which was g77 compatible for name mangling (but not the
> I/O library), got burned when gfortran decided to mangle names
> differently by default. Oh well.

Admittedly, it is not only the name mangling but also the module
information file structure that is an issue. However the advantage
of not requiring a preprocessor more than outweighs the disadvantage
in my opinion.

Also note the variance in OP's posting: Portability and
binary compatibility are two different items. The former to my
knowledge concerns itself with achieving the same results
starting out from a given source code. binary compatibility is
a much stronger requirement.

>
> And for the Fortran 9X world, well, there was obvious choice to
> imitate.
>
> -- g
>

<henrikholst80> wrote:

> 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.

All this has almost nothing to do with modules as a language design
issue. Binary compatibility between different compilers, even on the
same architecture, has always been a serious issue long before modules.
In limitted circumstances, you can sometimes make it work, but the
problems are great.

While binary compatibility issues aren't the top FAQ here, they
certainly are on it. People are continually asking about problems with
getting a library that was compiled for one compiler to work with a
different one - sometimes even with a different version of the same
vendor's compiler. This happens regardless of whether modules are
involved or not.

Yes, modules add some extra issues, but if you are using binary
compatibility as a major means of evaluating language features, then I
think you will find it a pretty inadequate measure for most purposes.

You mention C interop. Although you label it as sarcasm, I'd say it
shows that you are not very familliar with the C interop stuff. I might
note that the C interop features specifically are designed to also
facilitate interoperation with other languages. That does include, for
example, Fortran. It would depend on a vendor wanting to support it, but
the C interop stuff can be used to interoperate with such things as
other Fortran compilers. This was an intentional part of the design.

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

henrikholst80 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.

Yeah, so? I use 4 different compilers on my linux box for testing. For swapping out
libraries and module files, I use a simple script.

Are you also rankled when the code you compiled on your SGI doesn't run on your Sun? Or
IBM? Or HP? Or any of the vice versas?

> Also they create a terrible mess
> in the Make scripts.

My makefiles look exactly the same as do my dependency lists compared to my f77 days. (I
don't use *.mods as dependencies in suffix rules, just *.o and *.f90,*.F90)

And anyway, nobody generates dependency lists by hand anymore. )


> I just cannot understand why Fortran 90 thought
> there was a need to reinvent the wheel - and make a terrible work
> while doing so?
>
> 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_
>
> Sun studio 12
> 00000000 T testmod.compute_
> 00000000 B testmod.x_
> 00000000 D testmod_
>
> Also the .mod file is different. <sarcasm>The new Fortran 2003
> standard talks about C integration. How about to start with Fortran <-
>> Fortran integration? </sarcasm>

Ah - you think the language standard somehow dictates implementation details and/or standards?

I don't even expect module files to be compatible across different versions of the *same*
compiler from a particular vendor, let alone between compilers from different vendors.

>
> This means that you cannot compile a library with say gfortran and use
> it in any other compiler.
>
> If you avoid using Fortran modules you can get something that is
> binary compatible and usable between the three compilers I have
> available and have also tested with. I have [1] a small example of how
> to write "module code" without using modules. It boils down to using
> INCLUDE instead. There are some negativisms with not using MODULES as
> well but not as many.

In my case, the makefile for you example would look the same whether or not I used modules
or externals+include.

cheers,

paulv
>
>
> Leading researchers is using Fortran 95 [2] with modules I guess I
> just have to bend over and recognize that this is broken but nobody
> but me seems to care about it. Also, if you look at the BLAS95
> proposal routines, you see lot's of dangerous code. You see unsafe
> EXTERN keywords. I would though out modules and replace it with type
> checking any day of the week (Do not confuse modules with
> interfaces.).
>
> I think Fortran 90 has lot's of nice features which I think is
> essential to a modern programming language. I know I don't have to
> follow everyone else and use MODULES. I don't even have to use Fortran
> 90. But since so many are choosing to use modules and seems fine with
> that - where did you dispose of the bodies of those who questioned it?
>
> Thanks for your comments. I would very very much like to hear what you
> have to say about these things.
>
> [1] http://na37.nada.kth.se/mediawiki/in..._the_seventies
> [2] http://www.cs.umd.edu/~stewart/matran/Matran.html
>
> Cheers,
> --
> Henrik Holst, Sweden
> http://www.csc.kth.se/~holst/contact.shtml
>


--
Paul van Delst Ride lots.
CIMSS @ NOAA/NCEP/EMC Eddy Merckx

"Greg Lindahl" <lindahl@pbm.com> wrote in message
news:4697dfff$1@news.meer.net...
> In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de>
wrote:
>
> > C++ has the same issues here, although there
> >may be more efforts to keep compatibility here
>
> Well, there are a lot of system libraries for C++, so for example on
> Linux, gcc and Intel and PathScale all have the same mangling. You
> can't have a viable compiler otherwise.
>

On Windows, however, there is less compatability. Watcom, Borland &
Microsoft all used different schemes. Since the aim was to share a DLL, this
was rather more upsetting than modules. And I believe this ocntinues -
Microsoft & gcc still seem to use different approaches.

> In the Fortran77 world, gfortran isn't even g77 compatible. So
> PathsScale, which was g77 compatible for name mangling (but not the
> I/O library), got burned when gfortran decided to mangle names
> differently by default. Oh well.
>

Was it gfotran that did the name mangling, or gcc? I believe there were
changes between gcc 3.x and 4.x. Since gfortran needs to be compatable with
gcc, my immediate suspicion is that the fault lies with gcc, not gfortran.

> And for the Fortran 9X world, well, there was obvious choice to
> imitate.
>
> -- g
>

glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Richard Maine wrote:
> (snip)
>
> > All this has almost nothing to do with modules as a language design
> > issue. Binary compatibility between different compilers, even on the
> > same architecture, has always been a serious issue long before modules.
> > In limitted circumstances, you can sometimes make it work, but the
> > problems are great.
>
> I would have thought that the biggest cause of non-compatibility
> was in argument passing.

That's one, but I wouldn't call it the biggest. In practice, as far as I
am aware, today you don't see a lot of different schemes on the same
architecture. MS has their two different ones.

I/O is a very big one. I'd suggest not even thinking about trying to
open a unit number with one Fortran compiler and then reading/writing to
it with another. I suppose there might be cases where it works... but
you get better odds in Vegas. :-( The core of the problem is that I/O
involves lots of support library stuff. The support libraries of
different compilers aren't likely to play well together.

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

Richard Maine wrote:
(snip)

> All this has almost nothing to do with modules as a language design
> issue. Binary compatibility between different compilers, even on the
> same architecture, has always been a serious issue long before modules.
> In limitted circumstances, you can sometimes make it work, but the
> problems are great.

I would have thought that the biggest cause of non-compatibility
was in argument passing. There are now ever more efficient methods
using registers in different ways.

In the olden days, everything went on the stack (on machines that
had a stack). For IA32 there was the caller pops/callee pops
difference, but not so much past that. (For C, one had to pass
pointers when calling Fortran, but that is a different question.)

It would have been nice to standardize name mangling, though,
so that if everything else worked the calls would work.

Oh well.

-- glen

Richard Maine wrote:

(snip)

> I/O is a very big one. I'd suggest not even thinking about trying to
> open a unit number with one Fortran compiler and then reading/writing to
> it with another. I suppose there might be cases where it works... but
> you get better odds in Vegas. :-( The core of the problem is that I/O
> involves lots of support library stuff. The support libraries of
> different compilers aren't likely to play well together.

Yes, I/O tends to vary, but for the kinds of libraries that
I think about there isn't much I/O. Error messages maybe,
but that can usually be done by a return code instead of printing
something.

Otherwise, yes.

-- glen