Fortran 90 modules suck for portability- why use them?
henrik...@gmail.com
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?
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.
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/index.php/Fortran_90_goes_back_to_the_seventies
[2] http://www.cs.umd.edu/~stewart/matran/Matran.html
Cheers,
--
Henrik Holst, Sweden
http://www.csc.kth.se/~holst/contact.shtml
Reinhold Bader
henrik...@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.
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.
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/index.php/Fortran_90_goes_back_to_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
Greg Lindahl
> 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
Reinhold Bader
Greg Lindahl wrote:
> In article <4697D5A2...@lrz.de>, Reinhold Bader <Ba...@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.
Richard Maine
> 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
Paul van Delst
> 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. :o)
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/index.php/Fortran_90_goes_back_to_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
max
"Greg Lindahl" <lin...@pbm.com> wrote in message
news:4697dfff$1...@news.meer.net...
> In article <4697D5A2...@lrz.de>, Reinhold Bader <Ba...@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.
glen herrmannsfeldt
(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
> 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.
glen herrmannsfeldt
(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
Steven G. Kargl
lin...@pbm.com (Greg Lindahl) writes:
> In article <4697D5A2...@lrz.de>, Reinhold Bader <Ba...@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.
This is an over simplication. You are aware of the -ff2c
option, right? PathScale and gfortran have the same problem
with g77 compatibility, and that is the I/O library.
> 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.
PathScale is welcomed to contribute code to achieve the desired
compatibility. To my knowledge, neither PathScale nor anyone
associated with PathScale has ever sent an email to for...@gcc.gnu.org
with a description of their name mangling scheme. Do you expect
the gfortran *volunteers* (as opposed to paid company employees) to
check the name mangling scheme of every available compiler and provide
compatibility?
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>> In the Fortran77 world, gfortran isn't even g77 compatible.
>
>This is an over simplication. You are aware of the -ff2c
>option, right?
Steve, it is clear that I am talking about name mangling. I am aware
of the various flags gfortran has for name mangling; PathScale has the
same ones, as does g77. The complaint is about the *default*.
>PathScale is welcomed to contribute code to achieve the desired
>compatibility.
It's already there in gfortran. You can stop writing needless
paragraphs about *volunteers* needing to check the mangling schemes of
other compilers when the code is already in your compiler, and g77,
and PathScale's, which is open source, and you're welcome to examine
it. I *volunteer* that you can use it under the GPL, and yeah,
PathScale already sent FSF a copyright assignment, and contributed
money to the FSF, but I know that GNU activity is so decentralized
that clueless individuals insult the wrong targets on a regular basis.
-- greg
Bil Kleb
> PathScale's, which is open source, and you're welcome to examine
> it. I *volunteer* that you can use it under the GPL
Thanks, I learn something everyday:
http://www.pathscale.com/gpl.html
Thanks,
--
Bil Kleb
http://funit.rubyforge.org
Thomas Koenig
[...]
> and PathScale's, which is open source, and you're welcome to examine
> it. I *volunteer* that you can use it under the GPL,
I can't seem to find that information on http://www.pathscale.com.
Can you give me a pointer?
Thanks!
Gary Scott
> In article <4697dfff$1...@news.meer.net>,
> lin...@pbm.com (Greg Lindahl) writes:
>
>>In article <4697D5A2...@lrz.de>, Reinhold Bader <Ba...@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.
>
>
> This is an over simplication. You are aware of the -ff2c
> option, right? PathScale and gfortran have the same problem
> with g77 compatibility, and that is the I/O library.
CVF has so many options to adjust nearly any calling mechanism
parameter, I think it could match just about any possibility. That's
what I want in a compiler. I don't care what it's defaults are as long
as it gives me the flexibility to make adjustments to match, assuming I
have a definition of the target.
>
>
>>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.
>
>
> PathScale is welcomed to contribute code to achieve the desired
> compatibility. To my knowledge, neither PathScale nor anyone
> associated with PathScale has ever sent an email to for...@gcc.gnu.org
> with a description of their name mangling scheme. Do you expect
> the gfortran *volunteers* (as opposed to paid company employees) to
> check the name mangling scheme of every available compiler and provide
> compatibility?
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Steven G. Kargl
lin...@pbm.com (Greg Lindahl) writes:
> In article <f79m0j$mk4$1...@gnus01.u.washington.edu>,
> Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>
>>> In the Fortran77 world, gfortran isn't even g77 compatible.
>>
>>This is an over simplication. You are aware of the -ff2c
>>option, right?
>
> Steve, it is clear that I am talking about name mangling. I am aware
> of the various flags gfortran has for name mangling; PathScale has the
> same ones, as does g77. The complaint is about the *default*.
Did g77 have modules? gfortran
>
>>PathScale is welcomed to contribute code to achieve the desired
>>compatibility.
(Restore carefully snipped sentence)
>> To my knowledge, neither PathScale nor anyone
>> associated with PathScale has ever sent an email to for...@gcc.gnu.org
>> with a description of their name mangling scheme.
>
> It's already there in gfortran. You can stop writing needless
> paragraphs about *volunteers* needing to check the mangling schemes of
> other compilers when the code is already in your compiler, and g77,
> and PathScale's, which is open source, and you're welcome to examine
> it. I *volunteer* that you can use it under the GPL, and yeah,
> PathScale already sent FSF a copyright assignment, and contributed
> money to the FSF, but I know that GNU activity is so decentralized
> that clueless individuals insult the wrong targets on a regular basis.
gfortran developers read for...@gcc.gnu.org. I've been subscribed
since the list was created. "Neither PathScale nor anyone associated
with PathScale" has ever made a request on this mailinglist. You're
more than welcomed to request that the default mangling be changed.
Of course, discussion would occur and someone will point out that the
name mangling was perhaps inherited from g95 (the other OSS compiler)
or the name mangling is in line with the other compiler front-ends
or chosen to piss Greg Lindahl off.
As far as PathScale's compiler being a under the GPL. The document at
http://www.pathscale.com/docs/LEGAL.pdf would suggest otherwise:
'Although some components, distributed in the product, are governed
by open source licenses, this does not imply that the whole is "free"
software. Since the original product distribution contains proprietary
and open source components, redistribution of its contents in its
entirety is prohibited.'
It's great that PathScale has contributed to the FSF. But, I can
assure you that none of that contribution directly impacted the
gfortran development.
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>> Steve, it is clear that I am talking about name mangling. I am aware
>> of the various flags gfortran has for name mangling; PathScale has the
>> same ones, as does g77. The complaint is about the *default*.
>
>Did g77 have modules? gfortran
No, and I wasn't talking about modules. That whole section of my
posting was labeled "Fortran 77".
>gfortran developers read for...@gcc.gnu.org. I've been subscribed
>since the list was created. "Neither PathScale nor anyone associated
>with PathScale" has ever made a request on this mailinglist.
Thanks for inviting me. Had you not insulted me recently, it might be
a pleasant invitation. The fact that gfortran changed the name mangling
fault from f2c to single-underscore doesn't seem to be something that
really needs mentioning, but hey...
>It's great that PathScale has contributed to the FSF. But, I can
>assure you that none of that contribution directly impacted the
>gfortran development.
I never claimed it did. I'm just pointing out that you were
pointlessly flaming a company that has written a lot of Free Software.
Apparently you don't care. Oh well.
-- greg
Greg Lindahl
Gary Scott <garyl...@sbcglobal.net> wrote:
>CVF has so many options to adjust nearly any calling mechanism
>parameter, I think it could match just about any possibility. That's
>what I want in a compiler.
That's also true about g77, gfortran, and PathScale's compiler. But I
*do* care about the default; many users don't like having to change
it.
-- greg
Gary Scott
I didn't mean to imply that the default is unimportant. I just think
that a better design for interfacing to foreign things like operating
system APIs is to fully define the interface explicitly rather than
trying to force everybody to use the same convention/defaults. As far
as ensuring that libraries are produced to be compatible with a foreign
compiler, again, it's nice to be able to specify -interface:cvf6 or
something as a composite of one or more sub-options. I'd prefer that I
also be able to specify the equivalent via those sub-options (might also
be nice to be able to define my own composite option keywords as well,
maybe through a compiler .ini process or profile). I also need to be
able to do this inline on a procedure by procedure basis though (!DEC$
...). If these features are available, then I'm relatively happy.
>
> -- greg
Steven G. Kargl
lin...@pbm.com (Greg Lindahl) writes:
> In article <f7aro4$k6c$1...@gnus01.u.washington.edu>,
> Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>
>>> Steve, it is clear that I am talking about name mangling. I am aware
>>> of the various flags gfortran has for name mangling; PathScale has the
>>> same ones, as does g77. The complaint is about the *default*.
>>
>>Did g77 have modules? gfortran
>
> No, and I wasn't talking about modules. That whole section of my
> posting was labeled "Fortran 77".
gfortran is a Fortran 95 compiler.
>
>>gfortran developers read for...@gcc.gnu.org. I've been subscribed
>>since the list was created. "Neither PathScale nor anyone associated
>>with PathScale" has ever made a request on this mailinglist.
>
> Thanks for inviting me. Had you not insulted me recently, it might be
> a pleasant invitation.
I don't speak for gfortran. I do take exception to those who
snipe at gfortran and its developers.
> The fact that gfortran changed the name mangling
> fault from f2c to single-underscore doesn't seem to be something that
> really needs mentioning, but hey...
There is more to g77 compatibility than a single-underscore. Since
you know all about the -ff2c option, I probably needn't quote the
docs but I will
The calling conventions used by `g77' (originally implemented in
`f2c') require functions that return type default `REAL' to
actually return the C type `double', and functions that return
type `COMPLEX' to return the values via an extra argument in the
calling sequence that points to where to store the return value.
Under the default GNU calling conventions, such functions simply
return their results as they would in GNU C--default `REAL'
functions return the C type `float', and `COMPLEX' functions
return the GNU C type `complex'.
Compatibility with GNU C out ranks compatibility with PathScale
(or unsupported g77).
>>It's great that PathScale has contributed to the FSF. But, I can
>>assure you that none of that contribution directly impacted the
>>gfortran development.
>
> I never claimed it did. I'm just pointing out that you were
> pointlessly flaming a company that has written a lot of Free Software.
> Apparently you don't care. Oh well.
I'm not flaming a company. I'm pointing out that PathScale
hasn't contributed any code to gfortran and yet the gfortran
developers are somehow to infer (and implement) the desires of
PathScale. PathScale has never tried to communicate with the
gfortran developers (other than your sniping in c.l.f).
Tobias Schlueter added the -ff2c option on 2005-05-10. gfortran
was introduced to GCC in 2003. PathScale had 2 years to contribute
code or even start a discussion on for...@gcc.gnu.org. Oh Well.
Tim Prince
>>
>>> CVF has so many options to adjust nearly any calling mechanism
>>> parameter, I think it could match just about any possibility. That's
>>> what I want in a compiler.
>>
> As far
> as ensuring that libraries are produced to be compatible with a foreign
> compiler, again, it's nice to be able to specify -interface:cvf6 or
> something as a composite of one or more sub-options.
>
Hardly any compiler is in a position to implement any useful degree of
low level compatibility with CVF. Microsoft withdrew compatibility with
portions of that interface when they introduced 64-bit support, after
which HP withdrew support for CVF. So, there hasn't been any support
organization, for several years, for any compiler able to work with that
interface. It seems unlikely that anyone would try to mix g95 or
gfortran with CVF objects. ifort 32-bit includes a cvf compatibility
option, but it's hardly a significant selling point. Compiler
developers certainly have to draw the line on multiple interface support
short of the point where the options can't be tested adequately or where
legal obstacles could arise.
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>> No, and I wasn't talking about modules. That whole section of my
>> posting was labeled "Fortran 77".
>
>gfortran is a Fortran 95 compiler.
If you aren't going to respond to what I wrote in my postings, please
don't respond to my postings. I was discussing f77 name mangling, not
f9X module issues.
>I don't speak for gfortran. I do take exception to those who
>snipe at gfortran and its developers.
I wasn't sniping at them. And you demean the entire gfortran community
when you take offense like this.
>There is more to g77 compatibility than a single-underscore. Since
>you know all about the -ff2c option, I probably needn't quote the
>docs but I will
If you look back on this newsgroup, you'll find that I have held
multiple long discussions about the f2c-abi in the past. Please stop
being an idiot.
In addition, I WAS ONLY TALKING ABOUT F77 NAME MANGLING.
> PathScale has never tried to communicate with the
> gfortran developers (other than your sniping in c.l.f).
If you look back in the history of this group, you'll find that I
asked about the f2c-abi issue here. No sniping, and I received a
professional answer. I had no idea that I should have also asked about
the f77 name mangling issue, but such is life.
Now go away. Please.
-- greg
Gary Scott
users are still using it because until a few weeks ago, there wasn't an
acceptable replacement product for it (and still only about 95% since
the VS PPE is a close but incomplete subset). IVF is now the compiler
that others need to strive to be as flexible as and as compatible with
as possible as it still has all of the flexibility that CVF had
regarding adjustment of argument passing conventions.
Steve Lionel
> 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.
I hesitate to insert myself into this thread, but there are some
aspects of "binary compatibility" which have been overlooked.
When you are looking at mixing objects from different compilers, there
are (at least) four significant aspects to consider:
1. Name mangling, as has been mentioned earlier. What I don't see
mentioned is that on Windows, Microsoft documents what the name
decoration conventions should be, at least as far as presence or
absence of a leading underscore and whether there's an @n suffix for
STDCALL. There is nothing written about case of the name, probably
because Fortran is one of the few "important" languages that is case-
insensitive. On Linux, there is no formal standard, other than "the
way gcc does it".
2. Calling convention - how arguments are passed, how function values
are returned, and how the stack is handled. Again, for Windows,
Microsoft documents this to some degree. On Linux, it's again "how gcc
does it", as far as I know. 32-bit Windows is the only variant where
there are two distinct calling conventions, C and STDCALL, where the
difference is in who pops the stack on return. DVF/CVF chose STDCALL
as the default as that's what MS Fortran PowerStation did, but Intel
Visual Fortran switched to C as that was compatible with most everyone
else.
3. Object code format - COFF or ELF? For debug info, STABS or DWARF?
There's great variation on this across platforms complicating mixing
and matching tools.
4. Language support library interfaces - this is the issue few people
understand. In the Fortran world, unlike C, there is not a common
specification for the language library - calls for doing I/O, etc.
Each compiler has its own set of interfaces and mixing objects of two
Fortran compilers is usually doomed to failure for this reason.
What's worse is when two compilers have a library routine of the same
global name but with different interfaces. This is why you can't open
unit 7 in code compiled with compiler A and read from the same unit 7
in code compiled with compiler B. Fortran's I/O is defined for use
with global state, and that makes it nearly impossible to have
interoperability across different implementations.
That said, most Fortran compilers, mainly of necessity of working with
C on their platforms, have developed the necessary extensions to adapt
calling and naming conventions as needed. The C Interoperability
features of F2003 go a long way towards eliminating the need for such
extensions in many cases, though as we've seen from past discussions,
some things such as 32-bit Windows STDCALL are not included and thus
still require extensions.
Steve
P.S. I love modules and encourage all my customers to use them.
Steven G. Kargl
lin...@pbm.com (Greg Lindahl) writes:
> In article <f7b2p3$poq$1...@gnus01.u.washington.edu>,
> Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>
>>> No, and I wasn't talking about modules. That whole section of my
>>> posting was labeled "Fortran 77".
>>
>>gfortran is a Fortran 95 compiler.
>
> If you aren't going to respond to what I wrote in my postings, please
> don't respond to my postings. I was discussing f77 name mangling, not
> f9X module issues.
I did respond to your initial post and what you wrote.
GL: In the Fortran77 world, gfortran isn't even g77 compatible.
I responded:
SK: This is an over simplication. You are aware of the -ff2c
SK: option, right? PathScale and gfortran have the same problem
SK: with g77 compatibility, and that is the I/O library.
You further stated:
GL: So PathsScale, which was g77 compatible for name mangling
GL: (but not the I/O library), got burned when gfortran decided
GL: to mangle names differently by default. Oh well.
Did you really need to punctuate your paragraph with the "Oh well."?
You may not mean it, but I interpret that "Oh well" as a backhanded
expression of disappointment with gfortran developers. I personally
put a large amount of time into providing g77 compatibility by
implementing many of the nonstandard g77 runtime library routines.
I also don't understand why you keep referring to the "Fortran77
world". Fortran 77 hasn't been the official Fortran language for
nearly 17 years, and official support for g77 was dropped when
GCC 4.0.0 was releases over 2 years ago. Sorry, Greg, but all your
whining about what the gfortran developers should have done simply
denigrates all the effort that the developers have put into gfortran.
If you don't like gfortran, then don't use. If PathScale finds it too
difficult to support the gfortran name mangling scheme, then don't
offer a compiler switch. Like g77, in a few more years, gfortran will
be the de facto standard Fortran 95 (if not Fortran 2003) compiler.
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>I did respond to your initial post and what you wrote.
Steve, I have repeated exactly what I was talking about, so even if
you found the initial email unclear, you should now be clear about
exactly what I was referring to, namely the change of name-mangling
default from g2c underscoring to single underscores. F77 only comes
into it because I'm not referring to mangling of module names.
>Did you really need to punctuate your paragraph with the "Oh well."?
Had I known you were going to go off on a childish tirade as a result,
no.
-- greg
Steven G. Kargl
lin...@pbm.com (Greg Lindahl) writes:
>
> If you look back in the history of this group, you'll find that I
> asked about the f2c-abi issue here. No sniping, and I received a
> professional answer. I had no idea that I should have also asked about
> the f77 name mangling issue, but such is life.
I see you have discussed the f2c-abi. It appears that PathScale
chnaged its default to match the "f2c brain-damage".
https://www.x86-64.org/pipermail/discuss/2004-August/005044.html
Greg Lindahl
Steven G. Kargl <ka...@troutmask.apl.washington.edu> wrote:
>I see you have discussed the f2c-abi. It appears that PathScale
>chnaged its default to match the "f2c brain-damage".
>
>https://www.x86-64.org/pipermail/discuss/2004-August/005044.html
No, if you read more carefully, you'll see that I said the reverse:
I was saying that we already didn't do the f2c-abi by default, and
didn't want f2c-abi to be the default in the x86-64 Fortran ABI.
We added the ability to set mangling and f2c-abi on a per-symbol
basis, and a modest number of customers use this feature. It's good
enough to easily link to numerical libs (actually written in C) like
ACML, without having to compile a version specifically for PathScale.
-- greg
John Harper
Richard Maine <nos...@see.signature> wrote:
>glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>>
>> I would have thought that the biggest cause of non-compatibility
>> was in argument passing.
>
>open a unit number with one Fortran compiler and then reading/writing to
>it with another.
Indeed. And if you're using a precompiled package you may not even know
what it was compiled with. So it's not surprising that the test program
below gave three different outputs with three different compilers on the
same machine, all using the same NAG routines installed on it.
* PROGRAM nagio in file nagiotest.f line 1
* PROGRAM nagio in file nagiotest.f line 2
* NAG routine x04acf(iounit,filenm,mode,ifail) opens unit iounit to read
* if mode = 0, write if mode = 1, from/to external file named filenm.
* NAG routine x04bbf(iounit,rec,ifail) reads 1 record, rec, from iounit
* If ifail=0 on entry to either, it's non-zero on exit if error occurred.
PROGRAM nagio
IMPLICIT NONE
INTEGER ionag ,iof77 ,mode ,ifail
CHARACTER rec*80
DATA ionag/36/,iof77/37/,mode/0/,ifail/0/
INTEGER ltrim
EXTERNAL ltrim,x04baf,x04acf,x04bbf,testio
CALL x04acf(ionag,'nagiotest.f',mode,ifail)
ifail = 0
CALL x04bbf(ionag,rec,ifail)
CALL testio(ionag,'ionag','x04bbf',rec(1:ltrim(rec)),ifail)
READ(ionag,'(A)',IOSTAT=ifail) rec
CALL testio(ionag,'ionag','READ ',rec(1:ltrim(rec)),ifail)
OPEN(iof77,FILE='nagiotest.f',IOSTAT=ifail)
CALL x04bbf(iof77,rec,ifail)
CALL testio(iof77,'iof77','x04bbf',rec(1:ltrim(rec)),ifail)
READ(iof77,'(A)',IOSTAT=ifail) rec
CALL testio(iof77,'iof77','READ ',rec(1:ltrim(rec)),ifail)
END
INTEGER FUNCTION ltrim(string)
IMPLICIT NONE
CHARACTER*(*) string
* F77 equivalent of f95 len_trim
INTEGER i
DO i = len(string),2,-1
IF (string(i:i).NE.' ') GOTO 666
END DO
666 ltrim = i
END
SUBROUTINE testio(iounit,ioname,method,rec,ifail)
IMPLICIT NONE
INTEGER iounit ,ifail
CHARACTER*(*) ioname,method,rec
IF (ifail.NE.0) THEN
PRINT '(A,I3,2A)','Error reading unit',iounit,' with ',method
ifail = 0
END IF
PRINT '(7A)','With unit ',ioname,' and ',method,': "',rec,'"'
END
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
robert....@sun.com
> 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
> 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
Steve Lionel
> > 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?
No - this was an area where we messed up, but once this was called to
our attention within the past year, we did something about it. In a
future version, the default module decoration will not conflict with a
possible user name. On Linux and Mac, _MP_ will be used since the
default is to downcase the name. A switch will be available to get
the old behavior. On Windows, _mp_ is used because the default there
is to upcase names.
Personally, I wish we (and this decision dates back to DEC Fortran 90)
had chosen a decoration using a character not allowed in names, as I
see Sun does. But we decided not to "fix" the issue in that radical a
fashion for something unlikely to occur in real programs. As it is,
some users will need to adjust references to module variables or
routines when called from outside Fortran.
Steve Lionel
Software Development Products
Intel Corporation
robert....@sun.com
> Personally, I wish we (and this decision dates back to DEC Fortran 90)
> had chosen a decoration using a character not allowed in names, as I
> see Sun does.
It's a mixed bag. We get complaints from users who have to
escape the `.' with a `\' when using the linker names while
debugging. On the whole, I prefer the `.' nonetheless.
Bob Corbett
Arjen Markus
...
> 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.
>
Will there not be a problem with other resources as well?
For instance: pointers to allocated memory, intermediate
results (arrays for instance) returned by functions and so on?
I do not know enough about how the various C compilers handle
this, but from what I have read about the alternative libraries
for dealing with allocating and freeing memory, I doubt this
will work smoothly in that case either.
And of course, in C one should never rely on the contents of
system-defined structures like FILE ...
Regards,
Arjen
Jan Vorbrüggen
You were, and you started the sniping.
> And you demean the entire gfortran community when you take offense
> like this.
You got that wrong by 180 degress: It's your behaviour that is regularly
over-agressive when given the opportunity. The only reason people tolerate
your behaviour is because of your otherwise good technical contributions, and
because you give as window, as it were, into PathScale. Of course, at this
point this is my personal opinion only, but I am convinced that this is a
commonly-held position here.
> In addition, I WAS ONLY TALKING ABOUT F77 NAME MANGLING.
What is F77 name mangling, please? Is there still a compiler under regular
development that is _only_ an F77 compiler, so that this designation might
make sense?
Jan
Jan Vorbrüggen
> so that if everything else worked the calls would work.
The problem with doing that, though, is that things might only _appear_ to
work. Failure symptoms are potentially incorrect results (queue: FP functions
returning or expecting single- vs. double-precision results), strange I/O
behaviour or code that fails in strange ways (for instance, error message
output is only used when an error occurs, and because of different interfaces
in the support library, the program crashes at the point you need this
information most).
For C++, Stroustrup even recommended different compilers intentionally use
different name-mangling schemes for just this reason.
Jan
Greg Lindahl
Jan Vorbrüggen <jvorbr...@not-mediasec.de> wrote:
>What is F77 name mangling, please? Is there still a compiler under regular
>development that is _only_ an F77 compiler, so that this designation might
>make sense?
Non-module name mangling.
F9X incorporates all of F77, so the name makes sense.
-- greg
Kevin G. Rhoads
>development that is _only_ an F77 compiler, so that this designation might
>make sense?
OpenWatcom F77's code generator is shared with the C/C++ codegen,
which is under regular development.