Home > Archive > Fortran > July 2007 > Re: Fortran 90 modules suck for portability- why use them?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Fortran 90 modules suck for portability- why use them?
|
|
| Steven G. Kargl 2007-07-14, 4:15 am |
| In article <4697dfff$1@news.meer.net>,
lindahl@pbm.com (Greg Lindahl) writes:
> In article <4697D5A2.8050300@lrz.de>, Reinhold Bader <Bader@lrz.de> wrote:
>
>
> 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 fortran@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?
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Greg Lindahl 2007-07-14, 4:15 am |
| In article <f79m0j$mk4$1@gnus01.u.washington.edu>,
Steven G. Kargl <kargl@troutmask.apl.washington.edu> wrote:
>
>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
| |
|
|
| Thomas Koenig 2007-07-14, 7:07 pm |
| On 2007-07-14, Greg Lindahl <lindahl@pbm.com> wrote:
[...]
> 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 2007-07-14, 7:07 pm |
| Steven G. Kargl wrote:
> In article <4697dfff$1@news.meer.net>,
> lindahl@pbm.com (Greg Lindahl) writes:
>
>
>
> 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.
>
>
>
>
> 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 fortran@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
| |
| Greg Lindahl 2007-07-14, 7:07 pm |
| In article <WX5mi.10201$rL1.7191@newssvr19.news.prodigy.net>,
Gary Scott <garylscott@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 2007-07-14, 7:07 pm |
| Greg Lindahl wrote:
> In article <WX5mi.10201$rL1.7191@newssvr19.news.prodigy.net>,
> Gary Scott <garylscott@sbcglobal.net> wrote:
>
>
>
>
> 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.
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
>
--
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
| |
| Tim Prince 2007-07-14, 7:07 pm |
| Gary Scott wrote:
> 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.
| |
| Gary Scott 2007-07-14, 7:07 pm |
| Tim Prince wrote:
> Gary Scott wrote:
>
>
> 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.
90 percent of all pcs are still 32-bit and a large percentage of CVF
users are still using it because until a few w s 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.
--
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
|
|
|
|
|