Fortran - GNU Fortran 95: Opinions?

Author

GNU Fortran 95: Opinions?

Scott Robert Ladd

2004-10-29, 3:58 pm

Hi,

gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
Collection, GCC (http://gcc.gnu.org).

Since gfortran is still in development, I know many people have not
had a chance to use it. Snapshots are available from the GCC web site.

While an official release is still several months away, I'm interested in
knowing what Fortraners want from gfortran.

Note that I have *no* official capacity in terms of gfortran, though I
submit patches and do testing. For what it's worth, I'm a Fortran 95
programmer who wants to see GCC be more useful to the Fortran community. A
free compiler helps everyone, including commercial vendors, by making
Fortran 95 readily available.

I assume that compiling g77 code is a priority, as is correctly compiling
Fortran 95.

OpenMP won't be available until later, though progress is being made.

How important is MPI -- MPICH in particular? I'm considering waiting to
pursue this further until Open-MPI has its initial release in November.

Thanks for considered opinions.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Michael Prager

2004-10-29, 3:58 pm

Scott Robert Ladd <coyote@coyotegulch.com> wrote:

>gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
>replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
>Collection, GCC (http://gcc.gnu.org).
>
>While an official release is still several months away, I'm interested in
>knowing what Fortraners want from gfortran.

I would like it to install and run under Windows easily. By
that, I mean the user should not have to find and install other
software (gcc, Cygwin) nor set up any options beyond environment
variables. In other words, it should be as easy to install as a
commercial product.

(A substantial free program that installs cleanly and easily is
the statistical package R, which can be installed and used by an
OS idiot. http://www.r-project.org/ )

>How important is MPI -- MPICH in particular? I'm considering waiting to
>pursue this further until Open-MPI has its initial release in November.

Use of multiple processors by a single program is not important
to my work right now.

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Gordon Sande

2004-10-29, 3:58 pm

Michael Prager wrote:
> Scott Robert Ladd <coyote@coyotegulch.com> wrote:
>
>
>
>
> I would like it to install and run under Windows easily. By
> that, I mean the user should not have to find and install other
> software (gcc, Cygwin) nor set up any options beyond environment
> variables. In other words, it should be as easy to install as a
> commercial product.

Fortran programmers do not want to be Linux/Unix/whatever hackers
so this packaging is important. Also the installation should not
step all over existing software.

gfortran caused my demo version of NAG f95 to suddenly issue
gfortran error messages. gfortran was instantly history for me
as NAG reinstalled with no fuss and stopped issuing gfortran
error messages. It seems that Mac Os X is a standard Unix (good
thing) but that means that there can only be one f95 in the
standard place for installed software (not a good thing in the
circumstances!).

> (A substantial free program that installs cleanly and easily is
> the statistical package R, which can be installed and used by an
> OS idiot. http://www.r-project.org/ )
>
>
>
>
> Use of multiple processors by a single program is not important
> to my work right now.
>
>

Rich Townsend

2004-10-29, 3:58 pm

Scott Robert Ladd wrote:
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>
> Note that I have *no* official capacity in terms of gfortran, though I
> submit patches and do testing. For what it's worth, I'm a Fortran 95
> programmer who wants to see GCC be more useful to the Fortran community. A
> free compiler helps everyone, including commercial vendors, by making
> Fortran 95 readily available.
>
> I assume that compiling g77 code is a priority, as is correctly compiling
> Fortran 95.
>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.
>
> Thanks for considered opinions.
>

For my codes, a key issue is TR 15581 support -- allocatable
derived-type components and subroutine arguments. I simply cannot use
gfortran until this functionality is added.

cheers,

Rich

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

Kamaraju Kusumanchi

2004-10-29, 3:58 pm

Scott Robert Ladd wrote:
> Hi,
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>
> Note that I have *no* official capacity in terms of gfortran, though I
> submit patches and do testing. For what it's worth, I'm a Fortran 95
> programmer who wants to see GCC be more useful to the Fortran community. A
> free compiler helps everyone, including commercial vendors, by making
> Fortran 95 readily available.
>

First, let me thank your efforts to make gfortran better. It would be
nice to have a free fortran compiler.

1) I would like to have the run time array bounds checking option
(similar to ifc -C). I probably will not even try to code using gfortran
unless it has this option.

2) It would nice if the error messages describe the problem clearly.

3) Good illustrative documentation. I found IBM XL fortran's language
reference manual to be very useful.

4) MPI is good to have, but I can live without MPI.

5) Availability of makefiles to compile codes such as lapack, fftw,
lapack95 etc., I spent/wasted a lot of time to figure out various
options that could go into make files while compiling software... I know
that this varies from machine to machine. But if a makefile template is
shipped with gfortran for the most common platforms, it would attract
many people..

Those are just my views.
raju

David Ham

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 10:50:01 -0400
Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:

> Scott Robert Ladd <coyote@coyotegulch.com> wrote:
>
>
> I would like it to install and run under Windows easily. By
> that, I mean the user should not have to find and install other
> software (gcc, Cygwin) nor set up any options beyond environment
> variables. In other words, it should be as easy to install as a
> commercial product.

Let's get this straight. You want the new Fortran 95 front end to gcc to
work without gcc installed.

WTF?

David

TimC

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 at 14:27 GMT, Scott Robert Ladd (aka Bruce)
was almost, but not quite, entirely unlike tea:
> How important is MPI -- MPICH in particular? I'm considering waiting to

Very :)

> pursue this further until Open-MPI has its initial release in November.

Now, if only I could get the sy

min to acknowledge receipt of my
request for the installation of gfortran.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"Meddle not in the affairs of cats, for they are subtle, and will
piss on your computer." - Jeff Wilder

Mike Zulauf

2004-10-29, 3:58 pm

In article <c0tgd.28577$df2.26555@edtnps89>,
Gordon Sande <g.sande@worldnet.att.net> wrote:

> gfortran caused my demo version of NAG f95 to suddenly issue
> gfortran error messages. gfortran was instantly history for me
> as NAG reinstalled with no fuss and stopped issuing gfortran
> error messages. It seems that Mac Os X is a standard Unix (good
> thing) but that means that there can only be one f95 in the
> standard place for installed software (not a good thing in the
> circumstances!).

Depending on how you install these, you can have both. If you use fink,
then gfortran's version of f95 will live in an entirely different
location (under /sw).

Both compilers do use f95 as an executable name (though gfortran also
uses the name gfortran). You can fix this by setting your path
appropriately or using an alias to point to the NAG version for f95 or
other similar solutions.

This isn't an OS X problem. I would prefer it if the compilers used
unique names, however. . .

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Dick Hendrickson

2004-10-29, 3:58 pm

David Ham wrote:

> On Fri, 29 Oct 2004 10:50:01 -0400
> Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
>
>
>
>
> Let's get this straight. You want the new Fortran 95 front end to gcc to
> work without gcc installed.

I think the key words were "FIND AND INSTALL". It should be
easy to install, not require a Ph.D in finding *nix
downloads on the web.

Dick Hendrickson
>
> WTF?
>
> David

Gerry Thomas

2004-10-29, 3:58 pm

"Scott Robert Ladd" <coyote@coyotegulch.com> wrote in message
news:pan.2004.10.29.14.27.45.650185@coyotegulch.com...
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that
will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>
> Note that I have *no* official capacity in terms of gfortran, though I
> submit patches and do testing. For what it's worth, I'm a Fortran 95
> programmer who wants to see GCC be more useful to the Fortran community.
A
> free compiler helps everyone, including commercial vendors, by making
> Fortran 95 readily available.
>
> I assume that compiling g77 code is a priority, as is correctly compiling
> Fortran 95.
>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.
>
> Thanks for considered opinions.
>

Hear, hear. Thank you for championing GNU Fortran 95, a welcomed reprieve
from the usual pattering prattle of c.l.f. and its devotees.

--
Gerry T.
______
"Take away the right to say "XXXX" and you take away the right to say "XXXX
the government." " Lenny Bruce.

> --
> Scott Robert Ladd
> site: http://www.coyotegulch.com
> blog: http://chaoticcoyote.blogspot.com
>
>

Gordon Sande

2004-10-29, 3:58 pm

David Ham wrote:
> On Fri, 29 Oct 2004 10:50:01 -0400
> Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
>
>
>
>
> Let's get this straight. You want the new Fortran 95 front end to gcc to
> work without gcc installed.
>
> WTF?

If it requires seven support packages then have an installer that has
all seven there now. Rather than a long sequence of arcane diagnostics
that only a Unix guru would love. You know - all completely technically
correct and all absolutely totally uninformative. Why does gfortran
XXXXX about not having X11 if it is a command line compiler? Beats me.
But it took several days of mucking about to sort it out.

> David

Gordon Sande

2004-10-29, 3:58 pm

Mike Zulauf wrote:
> In article <c0tgd.28577$df2.26555@edtnps89>,
> Gordon Sande <g.sande@worldnet.att.net> wrote:
>
>
>
>
> Depending on how you install these, you can have both. If you use fink,
> then gfortran's version of f95 will live in an entirely different
> location (under /sw).
>
> Both compilers do use f95 as an executable name (though gfortran also
> uses the name gfortran). You can fix this by setting your path
> appropriately or using an alias to point to the NAG version for f95 or
> other similar solutions.

But since neither has useful documentation one is left in need of
the local Unix guru to come and perform a suitable rain dance.
Or one can pick exactly one and install and use it.

Neither deleted the files of the other except for the _little_ issue
you illustrate and that caused one to stop working. Why would one
install both if only one will end up working?

But if one was a Unix guru in need of job security then it is totally
a different issue. Remember the old programmers coloring book with the
picture labeled "This is a bug. Color it job security."

> This isn't an OS X problem. I would prefer it if the compilers used
> unique names, however. . .
>
> Mike
>

Jeff Layton

2004-10-29, 3:58 pm

Scott Robert Ladd wrote:
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>

(snip)

>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.

MPI is reallly not related to Fortran. It's just a set of libraries
that your Fortran code uses to message passing.

I haven't built any codes with gfortran yet, but I've built a number
of them with g77 using several MPI libraries. Never a problem.

So, I'm guessing that when gfortran is out in more widespread use,
linking in MPI libs will not be much of a problems (famous last
words - right?)\

Also, why are you waiting for OpenMPI? Remember that MPI is a standard
like Fortran. You can try MPICH now and then rebuild your codes with
OpenMPI when it's released. You won't be relearning anything except
for the specifics of compiling, linking, and running MPI codes. I would
suggest giving MPICH a whirl now and then building and trying OpenMPI
when it's available (it should be a good MPI implementation).

Jeff

Scott Robert Ladd

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 12:45:25 -0400, Jeff Layton wrote:
> MPI is reallly not related to Fortran. It's just a set of libraries
> that your Fortran code uses to message passing.

I realize that -- but MPI is something used by many Fortran programmers.

> So, I'm guessing that when gfortran is out in more widespread use,
> linking in MPI libs will not be much of a problems (famous last
> words - right?)

MPICH does not configure properly with gfortran; I'm trying to puzzle out
the problem, which appears to be in the configuration and problems with a
very few gfortran intrinsics.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Mike Zulauf

2004-10-29, 3:58 pm

In article <Jeugd.28600$df2.14927@edtnps89>,
Gordon Sande <g.sande@worldnet.att.net> wrote:

> Mike Zulauf wrote:
>
> But since neither has useful documentation one is left in need of
> the local Unix guru to come and perform a suitable rain dance.
> Or one can pick exactly one and install and use it.

I pretty much agree with what you say. My main reason for posting was
to explain the cause of the error, and to point out that it really has
nothing to do with OS X.

> Neither deleted the files of the other except for the _little_ issue
> you illustrate and that caused one to stop working. Why would one
> install both if only one will end up working?

You wouldn't, unless you can figure out the cause and fix it. Which you
can, with a little help.

But I agree you shouldn't have to do this. This is due to _both_ NAG
and the gfortran people. IMHO, neither should use f95 as their
executable name.

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Michael Prager

2004-10-29, 3:58 pm

David Ham <d.a.ham@citg.tudelft.nl> wrote:

>On Fri, 29 Oct 2004 10:50:01 -0400
>Michael Prager <Mike.Prager.indigo@noaa.gov> wrote:
>
>
>Let's get this straight. You want the new Fortran 95 front end to gcc to
>work without gcc installed.
>
>WTF?
>
>David

The answer has been given by others, but I'll give it on my own
behalf, also.

Yes, the key words are USER, FIND and INSTALL. The user of a
compiler should not have to care -- or even know -- whether it
is a front end to another compiler. A single installer can and
should include everything necessary.

Of course, those who develop gfortran have the privilege of
deciding how to package it. If they want the widest possible
use, they will make it easy for Windows users to install and run
without having to become expert in parts of *nix.

The same goes for commercial software! That's why I've never
tried a certain commercial compiler, though I hear it's fast.

--
Mike Prager, NOAA, Beaufort, NC
Address spam-trapped; remove color to reply.
* Opinions expressed are personal and not represented otherwise.
* Any use of tradenames does not constitute a NOAA endorsement.

Scott Robert Ladd

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 10:41:58 -0700, Mike Zulauf wrote:
> But I agree you shouldn't have to do this. This is due to _both_ NAG
> and the gfortran people. IMHO, neither should use f95 as their
> executable name.

The name of gfortran's executable is... "gfortran" -- and it has been for
several months. So I hope that solves any conflicts with other compilers.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Dave Seaman

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 13:42:21 -0400, Michael Prager wrote:
> David Ham <d.a.ham@citg.tudelft.nl> wrote:

[color=darkred]
> The answer has been given by others, but I'll give it on my own
> behalf, also.

> Yes, the key words are USER, FIND and INSTALL. The user of a
> compiler should not have to care -- or even know -- whether it
> is a front end to another compiler. A single installer can and
> should include everything necessary.

For example, the installer for GNU Pascal (gpc) under Mac OS X installs a
private copy of gcc for use by the gpc front end, and the user probably won't
even be aware that this has happened except by looking at the README file.

--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>

Mike Zulauf

2004-10-29, 3:58 pm

In article <pan.2004.10.29.18.35.19.82770@coyotegulch.com>,
Scott Robert Ladd <coyote@coyotegulch.com> wrote:

> On Fri, 29 Oct 2004 10:41:58 -0700, Mike Zulauf wrote:
>
> The name of gfortran's executable is... "gfortran" -- and it has been for
> several months. So I hope that solves any conflicts with other compilers.

Well, the version I have is installed through fink on OS X, and in
addition to the gfortran executable, it also has a symbolic link named
f95 (which points to gfortran).

It's possible this link was added by the fink package maintainer - I
don't know.

The version of gfortran I have installed is:

GNU Fortran 95 (GCC 3.5.0 20040815 (experimental))

So that's a couple months old.

This isn't a problem for me (I know how to execute the specific "f95" I
want), but it obviously causes problems for some.

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Scott Robert Ladd

2004-10-29, 3:58 pm

On Fri, 29 Oct 2004 12:05:07 -0700, Mike Zulauf wrote:
> Well, the version I have is installed through fink on OS X, and in
> addition to the gfortran executable, it also has a symbolic link named
> f95 (which points to gfortran).

It must be fink, because that link is not created by the official gfortran
distribution.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Gordon Sande

2004-10-29, 3:58 pm

Scott Robert Ladd wrote:
> On Fri, 29 Oct 2004 12:05:07 -0700, Mike Zulauf wrote:
>
>
>
> It must be fink, because that link is not created by the official gfortran
> distribution.
>

To paraphrase an earlier poster who thought everyone should manually
install the various phases/components of GCC - fink, official, WTF?

E P Chandler

2004-10-29, 8:56 pm

Michael Prager <Mike.Prager.indigo@noaa.gov> wrote in message news:<m8v4o05s03o5uqs8985aqj46vpfe1rkth8@4ax.com>...
> David Ham <d.a.ham@citg.tudelft.nl> wrote:
>
>
> The answer has been given by others, but I'll give it on my own
> behalf, also.
>
> Yes, the key words are USER, FIND and INSTALL. The user of a
> compiler should not have to care -- or even know -- whether it
> is a front end to another compiler. A single installer can and
> should include everything necessary.
>
> Of course, those who develop gfortran have the privilege of
> deciding how to package it. If they want the widest possible
> use, they will make it easy for Windows users to install and run
> without having to become expert in parts of *nix.
>

A good example of a compiler that is easy to use and install is the
2.9.5 g77 version which comes in a small archive. Its root directory
can be almost anywhere, it need not be in \g77, for example. The user
does not need to set a series of environment variables to get it to
work except for the path to "bin". Only the components that are needed
to compile, assemble and link along with required libraries are
provided.

In the case of this g77, someone other than one of the developers
packaged it up, but the design should make it easy to run the
replacment for g77 in "relative" isolation.

(That's one reason I have a personal preference for MinGW over Cygwin.
There seems to be a lot less _other_ stuff you need or have to
install.)

Ideally the program should install and uninstall cleanly. If on
Windows it should not use the registry. Installing the program could
be as simple as unpacking an archive and un-installing could be as
simple as removing an entire directory sub tree.

Tim Prince

2004-10-30, 3:56 am

Scott Robert Ladd wrote:
>I'm interested in
knowing what Fortraners want from gfortran.
> I assume that compiling g77 code is a priority, as is correctly compiling
> Fortran 95.
>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.
If gfortran can compile applications built with g77, then lam-mpi
shouldn't be far off, even on Windows (cygwin). Do you have a reason for
preferring MPICH, other than that it may one day have better support on
commercial 64-bit Windows compilers? Or, is the connection I assumed
between lam and Open-MPI bogus?
gfortran runs better on 32-bit Windows than the gcc-4 which comes with
it, so I suppose gcc is as much of a limiting factor as anything. I had
no luck with them on 64-bit Windows; looks like a gcc porting project.
gfortran looks fairly good on the Intel EM64T 64-bit linux. I found a
few tests where it works better than one or another of the commercial
compilers available to me, as well as some where it came in last.

beliavsky@aol.com

2004-10-30, 3:56 am

Scott Robert Ladd <coyote@coyotegulch.com> wrote in message news:<pan.2004.10.29.14.27.45.650185@coyotegulch.com>...
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.

Thanks for working on gfortran. Others have emphasized the importance
of an easy installation procedure. On Windows, there are at least two
Fortran IDEs using g77 that are easy to install and use: Force at
http://www.nitnet.com.br/~alexande/ and VFort at
http://www.imamod.ru/~vab/vfort/ . It would be great if gfortran could
be wrapped in such an IDE. I'd guess that the gfortran developers
mostly use Linux, so they may not be the people to implement this.

It would be nice if gfortran caught most of the coding errors listed
at http://www.polyhedron.com/compare/linux/diagnose.html . I'd be
curious to know how gfortran and g95 currently do on this.

Thomas Koenig

2004-10-30, 3:56 am

Richard E Maine <nospam@see.signature> wrote:

>What I most want from it is just something that will compile
>standard-conforming f90 code.

Hear, hear.

After that works, I'd really like to have bounds checking.

Finally, I have always found the -trapuv option on SGIs very useful
(fill uninitialized variables with signalling NaNs). This is probably
more a back end issue, though.

Stig Kildegård Andersen

2004-10-30, 8:56 am

> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.

Thank your for working on gfortran: My list of wishes (for any fortran
compiler) is something like:
1. F95
2. TR15581
3. Correctness and robustness
4. Correctness and robustness once more as it is the most common showstopper
for me
5. Debuggging tools (array bounds, uninitialised varibles, meaningful error
messages)
6. Ability to link with MPI
7. Easy installation

Kind Regards,
Stig Kildegård

Joost VandeVondele

2004-10-30, 8:56 am

Richard E Maine <nospam@see.signature> wrote in message
> I might add that I'm quite pleased with what I see from g95 so far.
> Namely, it runs the codes of mine that I tried it on.

I'm happy that it has been ('is' actually) the priority to get a
conforming f95 compiler. It is getting increasingly difficult to find
standard conforming code that breaks g95 in new and unexpected ways
(pointers to such code are still most welcome).

> Performance is mediocre, but it runs them.

I hope that some of the performance issues will be addressed in the
coming months. However, even though I'm sure you know, I would like to
mention that g95, like all gcc based compilers, but contrary to some
commercial compilers, generates completely unoptimised code by
default. E.g. just specifying -O2 improves the performance of my
application by roughly a factor five (which is still quite a bit
slower than the best other compilers).

Cheers,

Joost

Scott Robert Ladd

2004-10-30, 3:56 pm

On Fri, 29 Oct 2004 21:27:56 -0700, Richard E Maine wrote:
> What I most want from it is just something that will compile
> standard-conforming f90 code. F95 would be a nice extra (and would be
> second on my list), but seriously, I'd be majorly pleased if it would
> even do f90. It isn't there yet. Making progress, I know, but it
> isn't there. I ought to spend the time to send in some bug reports.
> Just recently managed to install it and haven't had the time to put
> togethger bug reports yet. (Saw several bugs to report).

If you simply have a list of bugs, I can go ahead and get those entered
into the GCC bugzilla. One thing I'm looking for is code that stresses
F90/95 compilers, for use in the test suite.

> I hesitate to dilute my wishes by distracting attention from that very
> important first step.

I think full Fortran 95 is an essential and attainable goal.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Ken Plotkin

2004-10-30, 3:56 pm

On Fri, 29 Oct 2004 08:59:15 -0700, Mike Zulauf
<mazulauf@met.utah.edu> wrote:

[snip]
>This isn't an OS X problem. I would prefer it if the compilers used
>unique names, however. . .

I've had three Fortran compilers on my PC at one time...MS Fortan 5.1,
MS Powerstation 1, and CVF. I dealt with the problem, for a while, by
a set of BAT files that would re-set the path and environment
variables to the ones I needed for each.

That became harder and harder to implement with each new version of
Windows, as environment variable handling (especially if directory
names have spaces) changed from version to version. Fortunately, the
older stuff is past its time and now I just use CVF.

But unique names would definitely be helpful.

I'm not likely to use GNU Fortran - I'm very happy with commercial
products - but the chances of my even trying it for a look-see are nil
if its installation would affect my setup.

Ken Plotkin

James Van Buskirk

2004-10-30, 3:56 pm

"Scott Robert Ladd" <coyote@coyotegulch.com> wrote in message
news:pan.2004.10.30.16.18.41.186803@coyotegulch.com...

> One thing I'm looking for is code that stresses
> F90/95 compilers, for use in the test suite.

Oh, I've got plenty of that. There are even a couple of toughies
on my website, http://home.comcast.net/~kmbtib/index.html . scaled2h.f90
and conv2b.f90 seem to be a bit problematic. They also, if you can get
them to run, generate code that can itself give problems to compilers
because of its size, e.g. the output of scaled2h.f90 with an input of
12 seems to be rather on the large size as far as some compilers are
concerned. The programs have pretty good checks for correctness in
that the codes they generate are test programs that should yield errors
on the order of double precision epsilon. Unfortunately I don't have
the resources available to install anything more challenging than F on
'doze, so I can't test the current free compilers personally.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Richard E Maine

2004-10-31, 3:56 am

Scott Robert Ladd <coyote@coyotegulch.com> writes:

> On Fri, 29 Oct 2004 21:27:56 -0700, Richard E Maine wrote:
>
> If you simply have a list of bugs, I can go ahead and get those entered
> into the GCC bugzilla.

Sorry, but no, I don't have them in any shape to give to anyone.
That's the part that will take a little work. Not a huge amount,
but a little. What I have is things that happen in the process of
compiling about 30,000 lines of code or so. No point in me giving
you that. I'm sure that most of the problems can be illustrated
in a dozen lines or so of code. What I need to do is cut them down
to that essential; then they will be submittable.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Charles Russell

2004-10-31, 3:56 am

"Thomas Koenig" wrote :
>
> After that works, I'd really like to have bounds checking.

A compiler without bounds checking would be pretty useless to me, and
enabling bounds check should not cost more than a factor of 2 or 3 in speed
so that it can be left switched on by those of us who do not write
"production code". This is needed if gfortran is to be an acceptable
replacement for g77. Other diagnostics should not be inferior to g77 when
using fortran 77 code. I modify old code more than I write new code, and
one concern with gfortran is that it will kill g77.

Thomas Koenig

2004-10-31, 3:56 am

Charles Russell <STOPworworSPAM@bellsouth.net> wrote:

>"Thomas Koenig" wrote :

[color=darkred]
>A compiler without bounds checking would be pretty useless to me, and
>enabling bounds check should not cost more than a factor of 2 or 3 in speed

Depending on when bounds checking is inserted into the code, this might
be far too pessimistic.

Consider the following code, which does the equivalent of bounds
checking:

integer :: i,n
real :: a(100)

read (*,*) n
do i=1,n
if (i < 1 .or. i > 100) call bounds_exception
a(i) = i
end do

An optimizer could notice that i could only be larger than 100 if
n is larger than 100, and so move the testing code out of the loop.

Tim Prince

2004-10-31, 8:56 am

Scott Robert Ladd wrote:
> On Fri, 29 Oct 2004 21:27:56 -0700, Richard E Maine wrote:
>
>
>
> If you simply have a list of bugs, I can go ahead and get those entered
> into the GCC bugzilla. One thing I'm looking for is code that stresses
> F90/95 compilers, for use in the test suite.
>
>
>
>
> I think full Fortran 95 is an essential and attainable goal.
>
Does this mean gfortran is ready for bugzilla entries covering
un-implemented syntax, like array assignments inside forall(), pack(),
unpack(), and other not so useful oddities? I assumed these were not a
priority at this stage, as no one has shown interest. pgf90 doesn't
support the array assignment in forall() either. I haven't found any
reason, other than it being f95 as opposed to f90, why only a few
compilers support it. Nor have I found them on any list of things
gfortran wants to postpone until later. I'd go so far as to wonder why
pack() et al exist, given lack of interest in making them perform
adequately, even when they work.

Tim Prince

2004-10-31, 8:56 am

James Van Buskirk wrote:
> "Scott Robert Ladd" <coyote@coyotegulch.com> wrote in message
> news:pan.2004.10.30.16.18.41.186803@coyotegulch.com...
>
>
>
>
> Oh, I've got plenty of that. There are even a couple of toughies
> on my website, http://home.comcast.net/~kmbtib/index.html . scaled2h.f90
> and conv2b.f90 seem to be a bit problematic. They also, if you can get
> them to run, generate code that can itself give problems to compilers
> because of its size, e.g. the output of scaled2h.f90 with an input of
> 12 seems to be rather on the large size as far as some compilers are
> concerned. The programs have pretty good checks for correctness in
> that the codes they generate are test programs that should yield errors
> on the order of double precision epsilon. Unfortunately I don't have
> the resources available to install anything more challenging than F on
> 'doze, so I can't test the current free compilers personally.
>
Does that mean you don't want to test gfortran until it becomes easier
to install on Windows than on linux? Sorry, I don't understand your
meaning. I haven't been able to get it running on 64-bit Windows, other
than by installing it under 32-bit Windows. I would assume that's not
what you mean, unless you so specify.

Charles Russell

2004-10-31, 8:56 am

"Thomas Koenig" wrote

speed[color=darkred]
>
> Depending on when bounds checking is inserted into the code, this might
> be far too pessimistic.
>

When Lahey discontinued f77l, their replacement fortran 95 compiler
sometimes slowed execution by a factor of more than 100 when bounds check
was
enabled. So I never used that compiler, adopting g77 instead. I only hope
that when g77 is replaced by gfortran, I don't encounter any similar nasty
surprises.

Charles Russell

2004-10-31, 3:56 pm

"Thomas Koenig" wrote
>
> Finally, I have always found the -trapuv option on SGIs very useful
> (fill uninitialized variables with signalling NaNs).

A more flexible option is to fill with a user-selected value. Preferably at
run time, not compile time, so large arrays do not lead to large executables
when initializing to zero (a suboptimal implementation in g77). Desirable,
but by no means as important as bounds check.

Gordon Sande

2004-10-31, 3:56 pm

Charles Russell wrote:
> "Thomas Koenig" wrote
>
>
>
> A more flexible option is to fill with a user-selected value. Preferably at
> run time, not compile time, so large arrays do not lead to large executables
> when initializing to zero (a suboptimal implementation in g77). Desirable,
> but by no means as important as bounds check.
>
>

A slight variant on this is the ability of the user to set variables to
the undefined value. For example, in a sparse matrix code one may do
storage compaction as required and it would be nice if the recovered
space could be made undefined again. This is both sufficiently useful
and so localized that I would view having to use a special vendor
debugging subroutine to "set to undefined" as worth the trouble.

Scott Robert Ladd

2004-10-31, 3:56 pm

On Sun, 31 Oct 2004 08:55:40 +0000, Tim Prince wrote:
> Does this mean gfortran is ready for bugzilla entries covering
> un-implemented syntax, like array assignments inside forall(), pack(),
> unpack(), and other not so useful oddities? I assumed these were not a
> priority at this stage, as no one has shown interest.

I'm showing an interest. ;)

Please, make bugzilla entries. I know there are some forall and pack
issues in bugzilla, but I don't know if these correspond to your concerns.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

Arnaud Desitter

2004-10-31, 3:56 pm

"Gordon Sande" <g.sande@worldnet.att.net> wrote in message
news:Dc7hd.62938$9b.60533@edtnps84...
>
>
> Charles Russell wrote:
>
> A slight variant on this is the ability of the user to set variables to
> the undefined value. For example, in a sparse matrix code one may do
> storage compaction as required and it would be nice if the recovered
> space could be made undefined again. This is both sufficiently useful
> and so localized that I would view having to use a special vendor
> debugging subroutine to "set to undefined" as worth the trouble.

There is a standard way to do it.
For all variables to be "undefined", call a routine such as:
subroutine undef_array(n,a)
integer, intent(in) :: n
real, intent(out):: a(n)
end

Associating an actual argument with an intent(out) dummy argument
"un-defines"
it. For instance, using the NAG compiler or the Salford compiler, the
value will be flagged as undefined and attempts to use it before an
assignment
will raise an error.

See http://ftp.aset.psu.edu/pub/ger/for...est/results.txt
tests UIN15

Even with Salford FTN77, it is possible to code some "undef_array" type
routines
that fill each byte with 0x80 (if my memory is correct). It interacts nicely
with /undef compiler option.

Regards,

Gordon Sande

2004-10-31, 3:56 pm

Arnaud Desitter wrote:
> "Gordon Sande" <g.sande@worldnet.att.net> wrote in message
> news:Dc7hd.62938$9b.60533@edtnps84...
>
>
>
> There is a standard way to do it.
> For all variables to be "undefined", call a routine such as:
> subroutine undef_array(n,a)
> integer, intent(in) :: n
> real, intent(out):: a(n)
> end
>
> Associating an actual argument with an intent(out) dummy argument
> "un-defines"
> it. For instance, using the NAG compiler or the Salford compiler, the
> value will be flagged as undefined and attempts to use it before an
> assignment
> will raise an error.

Neat! Thank you. This deserves to be in the documentation supplied
by the vendors.

> See http://ftp.aset.psu.edu/pub/ger/for...est/results.txt
> tests UIN15
>
> Even with Salford FTN77, it is possible to code some "undef_array" type
> routines
> that fill each byte with 0x80 (if my memory is correct). It interacts nicely
> with /undef compiler option.

The ability to hide the assignment from the compiler has always been
there but some of the suppliers of undefined checking have been a bit
coy on saying what the magic constant was. One could find it out with
determination but ...

> Regards,
>
>

James Van Buskirk

2004-10-31, 3:56 pm

"Tim Prince" <tprince@nospamcomputer.org> wrote in message
news:1T1hd.15771$6q2.9238@newssvr14.news.prodigy.com...

> Does that mean you don't want to test gfortran until it becomes easier
> to install on Windows than on linux? Sorry, I don't understand your
> meaning. I haven't been able to get it running on 64-bit Windows, other
> than by installing it under 32-bit Windows. I would assume that's not
> what you mean, unless you so specify.

No, I want to test gfortran & g95, but I can't do it until I can
install them. Is it that hard for the gnu folks to create a mingw
version, sort of the way F does it? If it's that hard for someone
to do it once at the author end, just imagine how much productivity
would be lost if hundreds of us at the user end had to figure out
how to do this. If it is as scary a process to install as it seems
from some threads in this forum it's not a working compiler from
my viewpoint.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Tim Prince

2004-11-01, 3:56 am

James Van Buskirk wrote:

>
>
> No, I want to test gfortran & g95, but I can't do it until I can
> install them. Is it that hard for the gnu folks to create a mingw
> version, sort of the way F does it?
>
I'm not holding my breath for mingw to become a gnu project, given the
obvious differences in philosophy. Cygwin isn't a gnu project either,
but it does aim to support much gnu software. I hesitate to jump in
here, given that others are more knowledgeable about these matters.

Bil Kleb

2004-11-01, 8:56 am

Scott Robert Ladd wrote:
> One thing I'm looking for is code that stresses
> F90/95 compilers, for use in the test suite.

Our FUN3D suite of codes seems to be a good test of F90/95
compilers,

http://fun3d.larc.nasa.gov

See the remarks on the g95 status page,

http://www.g95.org/g95_status.html

However, FUN3D is restricted to U.S. "people" only (some legal
definition that I can't seem to grok). To get a copy,

mailto:Fun_Support@larc.nasa.gov?subject=Code%20Request

describing the planned usage of the code (e.g., a test suite
for Fortran compiler development), your address, and if you
have one, a FAX number.

Regards,
--
Bil Kleb, Hampton, Virginia

beliavsky@aol.com

2004-11-01, 8:56 am

"James Van Buskirk" <not_valid@comcast.net> wrote in message news:<Ycbhd.28823$HA.22320@attbi_s01>...
> "Tim Prince" <tprince@nospamcomputer.org> wrote in message
> news:1T1hd.15771$6q2.9238@newssvr14.news.prodigy.com...
>
>
> No, I want to test gfortran & g95, but I can't do it until I can
> install them. Is it that hard for the gnu folks to create a mingw
> version, sort of the way F does it? If it's that hard for someone
> to do it once at the author end, just imagine how much productivity
> would be lost if hundreds of us at the user end had to figure out
> how to do this. If it is as scary a process to install as it seems
> from some threads in this forum it's not a working compiler from
> my viewpoint.

Regarding g95, if you search for "Windows" at the http://www.g95.org
site there are instructions on whom to get a self-installing Windows
compiler binary
that does not require Cygwin to be preinstalled -- the necessary
Cygwin dll is included. After it has been tested I think it will be
posted to the g95 site.

It does not require Cygwin to be preinstalled -- the necessary Cygwin
dll is included. After running it, I just needed to modify my PATH and
set a
LIBRARY_PATH variable. Then I could compile code, including your code
scaled2h.f90 and the codes it produced. The compiler occupies about 15
MB of disk space.

Paul Van Delst

2004-11-01, 3:57 pm

Tim Prince wrote:
> Does this mean gfortran is ready for bugzilla entries covering
> un-implemented syntax, like array assignments inside forall(), pack(),
> unpack(), and other not so useful oddities? I assumed these were not a
> priority at this stage, as no one has shown interest. pgf90 doesn't
> support the array assignment in forall() either. I haven't found any
> reason, other than it being f95 as opposed to f90, why only a few
> compilers support it. Nor have I found them on any list of things
> gfortran wants to postpone until later. I'd go so far as to wonder why
> pack() et al exist, given lack of interest in making them perform
> adequately, even when they work.

Huh. I use PACK() all the time, very handy -- I have very few progrmas/modules where it's
not used. But, I don't use it on large arrays so I can't comment on its performance.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Paul Van Delst

2004-11-01, 3:58 pm

Bil Kleb wrote:
> Scott Robert Ladd wrote:
>
>
>
> Our FUN3D suite of codes seems to be a good test of F90/95
> compilers,
>
> http://fun3d.larc.nasa.gov
>
> See the remarks on the g95 status page,
>
> http://www.g95.org/g95_status.html
>
> However, FUN3D is restricted to U.S. "people" only (some legal
> definition that I can't seem to grok).

Maybe it falls under ITAR restrictions? I have lawyers looking at my teeny little website
where I post my Fortran codes to ensure there's nothing there that violates it. (The level
of paranoia is quite bizarre to behold :o).

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

David Ham

2004-11-01, 3:58 pm

On Mon, 01 Nov 2004 09:40:59 -0500
Paul Van Delst <paul.vandelst@noaa.gov> wrote:

> Bil Kleb wrote:
>
> Maybe it falls under ITAR restrictions? I have lawyers looking at my teeny little website
> where I post my Fortran codes to ensure there's nothing there that violates it. (The level
> of paranoia is quite bizarre to behold :o).

Isn't there a more or less complete open source exemption from ITAR now?

David

Paul Van Delst

2004-11-01, 3:58 pm

David Ham wrote:
> On Mon, 01 Nov 2004 09:40:59 -0500
> Paul Van Delst <paul.vandelst@noaa.gov> wrote:
>
>
>
>
> Isn't there a more or less complete open source exemption from ITAR now?

Probably - but, me just being a lowly permanent resident as opposed to a US citizen, it's
just not worth the risk[*]. Luckily, I'm funded through a university and the lawyers told
me that as long as the code I post is the subject of just *my* research/work, then I'm
fine. If other people are involved (in particular gov't folk or contractors) then there
may need to be some sort of review process.

cheers,

paulv

[*] By risk, I mean it's mostly financial. If by some bizarre chance I did get
deported[**] I'd be spending a lot more time on the beach in Western
Australia so the physical hardship wouldn't bother me. :o)

[**] See how the paranoia is contagious? Crikey.

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Dick Hendrickson

2004-11-01, 3:58 pm

Gordon Sande wrote:
>
>
> Arnaud Desitter wrote:
>
>
>
> Neat! Thank you. This deserves to be in the documentation supplied
> by the vendors.
>
But, this doesn't necessarily do anything to the
variables. "Undefined" here is used in the Fortran sense
that the value isn't predictable. That doesn't mean that
the compiler MUST change it to something, only that the
programmer can't be sure about what MIGHT happen. It's
a compiler option if they choose to actually set some sort
of trapping pattern into the memory; they don't have to.

A standard conforming compiler could replace
call undef_array(100,array)
with
continue
and still be perfectly standard conforming.

Dick Hendrickson

[color=darkred]
>
>
> The ability to hide the assignment from the compiler has always been
> there but some of the suppliers of undefined checking have been a bit
> coy on saying what the magic constant was. One could find it out with
> determination but ...
>

Gordon Sande

2004-11-01, 3:58 pm

Dick Hendrickson wrote:
>
>
> Gordon Sande wrote:
>
> But, this doesn't necessarily do anything to the
> variables. "Undefined" here is used in the Fortran sense
> that the value isn't predictable. That doesn't mean that
> the compiler MUST change it to something, only that the
> programmer can't be sure about what MIGHT happen. It's
> a compiler option if they choose to actually set some sort
> of trapping pattern into the memory; they don't have to.
>
> A standard conforming compiler could replace
> call undef_array(100,array)
> with
> continue
> and still be perfectly standard conforming.
>
> Dick Hendrickson

Exactly! When running with aggressive undefined checking in place the
"compiler" will set the intent out variables to its magic values
BUT when the aggressive undefined checking is off the "compiler"
does nothing as the "undefinedness" is "only" a state of mind.
As you point out the compiler replaces things by a no-op or whatever
it chooses if either they do not have aggressive undefined checking
or it has not been enabled. Some compilers have the ability to make
undefined more than just a state of mind and it is a VERY useful
debugging tool to be able to apply.

The original question was how to get the magic value placed by the
user to get full benefit of the undefined checking through magic values.
Before the advent of intent ( out ) there was no elegant way of getting
to the undefined state. One had to resort to various hacks of hiding
assignments that involved the magic value. Now there is an elegant
path to undefinedness and the several vendors with undefined checking
seem to use it.

The worst thing about this suggestion is that someone else pointed it
out. :-(. I was stuck back in the days of F77 on WatFor and had not
thought about the impact of intent ( out ).

>
>

Paul Van Delst

2004-11-01, 3:58 pm

Gordon Sande wrote:
>
>
> Dick Hendrickson wrote:
>
>
> Exactly! When running with aggressive undefined checking in place the
> "compiler" will set the intent out variables to its magic values
> BUT when the aggressive undefined checking is off the "compiler"
> does nothing as the "undefinedness" is "only" a state of mind.
> As you point out the compiler replaces things by a no-op or whatever
> it chooses if either they do not have aggressive undefined checking
> or it has not been enabled. Some compilers have the ability to make
> undefined more than just a state of mind and it is a VERY useful
> debugging tool to be able to apply.
>
> The original question was how to get the magic value placed by the
> user to get full benefit of the undefined checking through magic values.
> Before the advent of intent ( out ) there was no elegant way of getting
> to the undefined state. One had to resort to various hacks of hiding
> assignments that involved the magic value. Now there is an elegant
> path to undefinedness and the several vendors with undefined checking
> seem to use it.
>
> The worst thing about this suggestion is that someone else pointed it
> out. :-(. I was stuck back in the days of F77 on WatFor and had not
> thought about the impact of intent ( out ).

I have several chunks missing from my ass because of this (and I believe Dick was the guy
on clf that pointed it out to me! :o). When I switched my code from f90 to f95 I changed
the way I define my structures from something like:

type :: x_type
integer :: n_points
integer, dimension(:), pointer :: a
real, dimension(:), pointer :: b
end type

to

type :: x_type
integer :: n_points = 0
integer, dimension(:), pointer :: a => NULL()
real, dimension(:), pointer :: b => NULL()
end type

If I had code where dummy args of type x_type had intent(out) and happened to be defined
upon input, massive memory leaks ensued.

I don't know if this behaviour is mandated by the standard (i.e. the structure contents
get "reset" to the values in the declaration as opposed to some compiler-specific
"undefined" value [or no-op]) but it occurs on every compiler/platform I use
(Linux-pgf90/lf95/ifort, IBM, SGI, Sun). For fortran-90 syntax with no initialisation in
the declaration, there was no resetting/undefining of the intent(out) structure components.

In the end, it was a pita to change everything, but I'm glad it happened. It made my code
standard conforming and it makes me think a lot more carefully about what's happening when
I supply dummy args with the intent attribute.

Can the same be made to apply (somehow) to regular old scalar arguments?

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Paul Van Delst

2004-11-01, 3:58 pm

Richard E Maine wrote:
> Paul Van Delst <paul.vandelst@noaa.gov> writes:
>
>
> Yes, it applies to scalars. The rank has nothing to do with it.
> Default initialization attaches to a type. Perhaps you are thinking
> of a structure as something other than a scalar - it isn't.
>
> But assuming what you probably meant instead of what you said, no
> you can't define default initializtion for intrinsic types. It is
> part of the type definition, and you don't get to define intrinsic
> types - the standard does.

Yes, what I was asking about was default initialization for intrinsic types. Dunno why I
used the word "scalars". Thanks for clarifying.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Dick Hendrickson

2004-11-01, 8:57 pm

[color=darkred]
> Gordon Sande wrote:
>

But, in a way, if compilers "really" support undefined
checking, you shouldn't need this hack. Compilers should,
at least, spray the stack with undefineds on entry and
allocate memory to an undefined status, etc. At least,
that's my opinion. The problem with a special
routine with intent(out) arguments is that you need several
of them to cover different types. You can make them
elemental and generic, so at least you don't have to
remember very many subroutine names. And worse, you need
to find the approximate right spot to put the call (and
if you knew for sure where to put it, you wouldn't
need to put it there ;) ). And finally, it can lead
to a false sense of security if you move the code to
a compiler that doesn't aggressively undefine undefined
variables (or if some twit changes the build procedure).

Still, it's a lot lot lot lot better than nothing.

Several years ago, the Fujitsu compiler was very aggressive
about checking undefined variables. They could find common
going out of scope and lots of other special cases. I
don't know if the technology lives on, nor if it was
significantly expensive at run-time.

Dick Hendrickson

James Van Buskirk

2004-11-02, 8:57 am

<beliavsky@aol.com> wrote in message
news:3064b51d.0411010345.4b5ad81b@posting.google.com...

> that does not require Cygwin to be preinstalled -- the necessary
> Cygwin dll is included. After it has been tested I think it will be
> posted to the g95 site.

OK, this looks interesting. If it makes it to the g95 site let us
know.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Salvatore Filippone

2004-11-02, 8:57 am

Scott Robert Ladd <coyote@coyotegulch.com> wrote in message news:<pan.2004.10.29.14.27.45.650185@coyotegulch.com>...
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>
> Note that I have *no* official capacity in terms of gfortran, though I
> submit patches and do testing. For what it's worth, I'm a Fortran 95
> programmer who wants to see GCC be more useful to the Fortran community. A
> free compiler helps everyone, including commercial vendors, by making
> Fortran 95 readily available.
>
> I assume that compiling g77 code is a priority, as is correctly compiling
> Fortran 95.
>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.
>
> Thanks for considered opinions.

1. Full Fortran 95 compliance
2. MPICH working (more than 98% of my Fortran codes are MPI)
3. TR 15581.
4. Debugging features (especially in the parallel context)

Of course this reflects my personal environment, YMMV

Salvatore Filippone
University of Rome "Tor Vergata"

Tim Prince

2004-11-02, 8:57 am

James Van Buskirk wrote:
> <beliavsky@aol.com> wrote in message
> news:3064b51d.0411010345.4b5ad81b@posting.google.com...
>
>
>
>
> OK, this looks interesting. If it makes it to the g95 site let us
> know.
>
Wouldn't that violate the cygwin license, unless all required sources
for both g95 and cygwin were posted to the site which includes cygwin dll?

Tobias Schlueter

2004-11-02, 3:57 pm

Gordon Sande wrote:
>
> Scott Robert Ladd wrote:
>
>
>
> To paraphrase an earlier poster who thought everyone should manually
> install the various phases/components of GCC - fink, official, WTF?
>
>
I think this (i.e. the fact that fink installs the f95 symlink
unconditionally) should be reported as a bug to the fink people. This problem
has _nothing_ to do with the official gfortran.

- Tobias Schlüter

Tobias Schlueter

2004-11-02, 3:57 pm

Gordon Sande wrote:
> If it requires seven support packages then have an installer that has
> all seven there now. Rather than a long sequence of arcane diagnostics
> that only a Unix guru would love. You know - all completely technically
> correct and all absolutely totally uninformative. Why does gfortran
> XXXXX about not having X11 if it is a command line compiler? Beats me.

This is a bug in fink's packaging, and should reported to the fink people.
This has nothing to do with gfortran. gfortran doesn't require X11.

As an aside, I agree that it is unfortunate from a user point of view that
there are no officially supported binary packages for gcc, so that one has to
resort to binaries created by outside groups (e.g. fink) if one wants to
simply use gcc, instead of compiling it, but given the sheer number of
platforms (host and target) supported by gcc, it is clear that there's no way
that he gcc people could supervise all the possible hazards involved in binary
packages for all possible combinations of architectures / OSes.

Regards,
- Tobias Schlüter

Tobias Schlueter

2004-11-02, 3:57 pm

Kamaraju Kusumanchi wrote:
> 1) I would like to have the run time array bounds checking option
> (similar to ifc -C). I probably will not even try to code using gfortran
> unless it has this option.

gfortran has an option for this, -fbounds-checking IIRC. It is documented in
the main gcc documentation, again IIRC.

> 2) It would nice if the error messages describe the problem clearly.

There's always a choice to be made where to put the available time. Right now,
I think most people have "making gfortran work better with valid code" as a
priority. But this point is taken, especially syntax errors in data
declarations or END statements of the various kinds can badly upset error
recovery in the parser currently.

> 3) Good illustrative documentation. I found IBM XL fortran's language
> reference manual to be very useful.

Writing documentation is something which is always difficult to get done in a
volunteer based project. It does happen, but admittedly our current
documentation is far from complete.

> 4) MPI is good to have, but I can live without MPI.

The move for adding MPI to gcc has only started a few w

s ago, so it's
definitely not going to be something which will be there soon.

>
> 5) Availability of makefiles to compile codes such as lapack, fftw,
> lapack95 etc., I spent/wasted a lot of time to figure out various
> options that could go into make files while compiling software... I know
> that this varies from machine to machine. But if a makefile template is
> shipped with gfortran for the most common platforms, it would attract
> many people..

Good point, I'll see about adding something like this to gfortran.org shortly.
Of course, if somebody has these templates for the different architectures
you're using, you're welcome to add them to gfortran.org yourself.

> Those are just my views.

And they're very much appreciated.

Regards,
- Tobias Schlüter

Charles Russell

2004-11-02, 3:57 pm

"Tobias Schlueter" wrote
>
>
> There's always a choice to be made where to put the available time. Right
now,
> I think most people have "making gfortran work better with valid code" as
a
> priority.

I have been told by a programmer that if good error handling is not designed
into code from the beginning, it is very hard to add it later.

Helge Avlesen

2004-11-02, 3:57 pm

Tobias Schlueter <tobias.schlueter@web.de> writes:

| The move for adding MPI to gcc has only started a few w

s ago, so it's
| definitely not going to be something which will be there soon.

MPI is already implemented in several libraries (MPICH, LAM,...) you
must confuse it with OpenMP, no?

Helge

Janne Blomqvist

2004-11-02, 3:57 pm

On 2004-11-02, Helge Avlesen <avle@ii.uib.no> wrote:
> Tobias Schlueter <tobias.schlueter@web.de> writes:
>
>| The move for adding MPI to gcc has only started a few w

s ago, so it's
>| definitely not going to be something which will be there soon.
>
> MPI is already implemented in several libraries (MPICH, LAM,...) you
> must confuse it with OpenMP, no?

....not to be

with OpenMPI, the upcoming über-open-source MPI
implementation. *sigh* I wish they would have named it something which
would be have been less prone to misunderstanding.

Perhaps they just wanted to tweak the noses of the OpenMP people? ;-)

--
Janne Blomqvist

Dave Seaman

2004-11-02, 3:57 pm

On Tue, 02 Nov 2004 15:59:59 +0100, Tobias Schlueter wrote:
> Gordon Sande wrote:

I didn't think anyone was claiming that fink is official. Quite the
contrary, in fact.
[color=darkred]
> I think this (i.e. the fact that fink installs the f95 symlink
> unconditionally) should be reported as a bug to the fink people. This problem
> has _nothing_ to do with the official gfortran.

It's possible that fink may have done that at one time, but I used fink
to install gfortran on my PowerBook just last Friday and I can confirm
that there is no f95 symlink installed by fink. They may have changed
that when f95 became available as another fink package.

--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>

Tobias Schlueter

2004-11-02, 3:57 pm

Charles Russell wrote:
> "Tobias Schlueter" wrote
>
>
>
> I have been told by a programmer that if good error handling is not
> designed into code from the beginning, it is very hard to add it later.
>

I knew someone would reply that.
Unfortunately, the code is mostly there already, so making it handle errors
more gracefully falls under this rule :-(

BTW usually the first error message is correct, and successive errors tend to
get worse, as the semantics of the program become less and less well defined.
[tongue-in-ch

]Maybe gfortran should behave like Turbo Pascal
did: stop after the first error[/tongue-in-ch

]

- Tobias Schlüter

Mike Zulauf

2004-11-02, 3:57 pm

In article <cm87n2$8j0$02$1@news.t-online.com>,
Tobias Schlueter <tobias.schlueter@web.de> wrote:

> As an aside, I agree that it is unfortunate from a user point of view that
> there are no officially supported binary packages for gcc, so that one has to
> resort to binaries created by outside groups (e.g. fink) if one wants to
> simply use gcc, instead of compiling it, but given the sheer number of
> platforms (host and target) supported by gcc, it is clear that there's no way
> that he gcc people could supervise all the possible hazards involved in binary
> packages for all possible combinations of architectures / OSes.

Well, at least with OS X, gcc is distributed by Apple as part of the
Developer's Tools (an optional install CD), or can be downloaded from
their Developer's web site. But for Fortran, you've got to go elsewhere.

There are quite a few other useful installation options (X11, X11 SDK,
BSD subsystem, etc).

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Mike Zulauf

2004-11-02, 3:57 pm

In article <cm8eln$fvq$1@mozo.cc.purdue.edu>,
Dave Seaman <dseaman@no.such.host> wrote:

> On Tue, 02 Nov 2004 15:59:59 +0100, Tobias Schlueter wrote:
>
>
> It's possible that fink may have done that at one time, but I used fink
> to install gfortran on my PowerBook just last Friday and I can confirm
> that there is no f95 symlink installed by fink. They may have changed
> that when f95 became available as another fink package.

It's certainly odd. My f95 link dated from August 23 (when I installed
the latest update of gfortran?).

I just removed gfortran, and then reinstalled it. And it recreated the
f95 link.

Mike

--
Mike Zulauf
mazulauf@met.utah.edu

Gordon Sande

2004-11-02, 3:57 pm

Tobias Schlueter wrote:
> Charles Russell wrote:
>
>
>
> I knew someone would reply that.
> Unfortunately, the code is mostly there already, so making it handle errors
> more gracefully falls under this rule :-(
>
> BTW usually the first error message is correct, and successive errors tend to
> get worse, as the semantics of the program become less and less well defined.
> [tongue-in-ch

]Maybe gfortran should behave like Turbo Pascal
> did: stop after the first error[/tongue-in-ch

]
>
> - Tobias Schlüter

Along time ago there was both Fortran G and Fortran H on IBM mainframes.

Fortran H error messages appeared at the end of the program unit with
a line number and a long paragraph giving a learned exposition on the
problem encountered.

Fortran G error messages appeared below the line with problems and had
a marker where they thought the problem was. The text was ofter just
"Error here" of something equally short.

Since most error messages misdiagnose the symptoms the Fortran G style
was actually more productive. Most error are of the fumble fingered
variety and attempting to make sense is more often humorous than not.
At least that is how the two compilers came across.

Rich Townsend

2004-11-02, 3:57 pm

Gordon Sande wrote:
>
>
> Tobias Schlueter wrote:
>
>
>
> Along time ago there was both Fortran G and Fortran H on IBM mainframes.
>
> Fortran H error messages appeared at the end of the program unit with
> a line number and a long paragraph giving a learned exposition on the
> problem encountered.
>
> Fortran G error messages appeared below the line with problems and had
> a marker where they thought the problem was. The text was ofter just
> "Error here" of something equally short.
>
> Since most error messages misdiagnose the symptoms the Fortran G style
> was actually more productive. Most error are of the fumble fingered
> variety and attempting to make sense is more often humorous than not.
> At least that is how the two compilers came across.
>

However, nothing beats the classic "lp0 on fire" for combining
hyperbole, crpyticness and humour.

:)

--
Dr Richard H D Townsend
Bartol Research Institute
University of Delaware

[ Delete VOID for valid email address ]

TimC

2004-11-02, 8:56 pm

On Tue, 02 Nov 2004 at 17:47 GMT, Gordon Sande (aka Bruce)
was almost, but not quite, entirely unlike tea:
> Fortran H error messages appeared at the end of the program unit with
> a line number and a long paragraph giving a learned exposition on the
> problem encountered.
>
> Fortran G error messages appeared below the line with problems and had
> a marker where they thought the problem was. The text was ofter just
> "Error here" of something equally short.
>
> Since most error messages misdiagnose the symptoms the Fortran G style
> was actually more productive. Most error are of the fumble fingered
> variety and attempting to make sense is more often humorous than not.
> At least that is how the two compilers came across.

I always get annoyed at the super duper long listing of errors that
certain compilers output. I even wrote a script to head the top 30
lines, and discard the rest. What is the chance of the latter pages of
errors being purely because of misunderstanding caused by earlier
errors? Certain compilers just keep on going well past the point where
they should have stopped.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
FORTRAN is a good example of a language which is easier to parse
using ad hoc techniques. -- D. Gries

Catherine Rees Lay

2004-11-03, 3:57 pm

In article <cm8i41$e5e$1@scrotar.nss.udel.edu>, Rich Townsend
<rhdt@barVOIDtol.udel.edu> writes
>
>However, nothing beats the classic "lp0 on fire" for combining
>hyperbole, crpyticness and humour.
>
>:)
>
>
My husband tells me he's got into the habit of coding silly error
messages for "this shouldn't happen" situations. If he codes a message
saying "logic error in routine xxx at line yy", the administrator who's
using the code will come and say "I got an error" and not remember what
it was. On the other hand, give them "out of cheese error" and they'll
remember it. He only writes in-house software, so he gets away with it.

Catherine (with a nod to Terry Pratchett).
--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Paul Van Delst

2004-11-03, 3:57 pm

Kamaraju Kusumanchi wrote:
> I am happy that you are interested in my suggestion. I have a better
> idea for linux users.
>
> If rpms, debs of compiled versions of blas, lapack, lapack95, fftw etc
> are made available that would be great. Currently on the netlib (I
> checked it before posting this) there are some rpms available
> (http://www.netlib.org/lapack95/). But they do not clearly mention which
> compiler they used for it.
>
> I would like to see something like this - a link from gfortran website
> which contains compiled software using gfortran for various
> architectures (i386, sparc, powerpc etc)...
>
> Someone on this list might say "what the hell? go and compile from
> sources?" But the lapack documentation is not so straightforward. It
> leaves many open ended questions for the novice who tries to use it. For
> example it says that, blas is needed to compile lapack which in turn is
> needed for lapack95. For a new user (who is not familiar with system
> administration stuff) this might be a daunting task. That is why, I
> think providing compiled versions of packages is a better idea. YMMV...

Keep in mind that a lot of people using Linux systems cannot use rpms to install stuff.
Not everyone has root (or some level of sudo) access to do those sorts of things. And I'll
wager that the number of people who do have that access is going to continue to decrease.

For those cases compilable sources (or precompiled libraries/binaries) are the go.

cheers,

paulv

--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC

Charles Russell

2004-11-03, 3:57 pm

"TimC" wrote
> I always get annoyed at the super duper long listing of errors that
> certain compilers output.

The best ones don't do this. (All-time best was DEC VAX fortran 77). One
likes to see all syntax errors listed on the first pass, like ftnchek does.
In fact, I was hoping that the front end of gfortran could eventually be
used to create a ftnchek for f90+.

Jugoslav Dujic

2004-11-03, 3:57 pm

Charles Russell wrote:
| "TimC" wrote
|| I always get annoyed at the super duper long listing of errors that
|| certain compilers output.
|
| The best ones don't do this. (All-time best was DEC VAX fortran 77). One
| likes to see all syntax errors listed on the first pass, like ftnchek does.
| In fact, I was hoping that the front end of gfortran could eventually be
| used to create a ftnchek for f90+.

CVF got better with the time, but (especially on a slow computer) it
still suffers from

<2-minute cooking of a long module>
....
Syntax error at line 4: ...

--
Jugoslav
___________
www.geocities.com/jdujic

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

beliavsky@aol.com

2004-11-03, 3:57 pm

"Jugoslav Dujic" <jdujic@yahoo.com> wrote:
>Charles Russell wrote:
>| "TimC" wrote
>|| I always get annoyed at the super duper long listing of errors that
>|| certain compilers output.
>|
>| The best ones don't do this. (All-time best was DEC VAX fortran 77).
One
>| likes to see all syntax errors listed on the first pass, like ftnchek
does.
>| In fact, I was hoping that the front end of gfortran could eventually
be
>| used to create a ftnchek for f90+.
>
>CVF got better with the time, but (especially on a slow computer) it
>still suffers from
>
><2-minute cooking of a long module>
>...
>Syntax error at line 4: ...

I agree that CVF can be relatively slow in compiling, although I rarely notice
it on my fast PC's nowadays. I think CVF becomes especially slow relative
to Lahey/Fujitsu when compiling a large source file. On a PC with a 2.8 GHz
Intel Pentium 4 and 512 MB of RAM, CVF 6.6c took 294 s, compared to 73 s
for LF95 5.7c to compile the 300K line translation of Slatec to free format
at http://www.csit.fsu.edu/~burkardt/f...atec/slatec.f90 . The times
for CVF and LF95 to compile the Numerical Recipes Fortran 77 library are
11 s vs. 7 s. The NRF77 library is composed of 352 relatively short source
files. All compilations were done with no optimization.

P.S. There is a lot of Fortran code at Burkhardt's site http://www.csit.fsu.edu/~burkardt/f_src/f_src.html
, including an easy-to-compile translation of Lapack to free source form.
I have compiled his codes with LF95, and he has fixed the occasional glitches
I have reported.

----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

David Ham

2004-11-03, 3:57 pm

On Wed, 03 Nov 2004 09:37:39 -0500
Paul Van Delst <paul.vandelst@noaa.gov> wrote:

> Kamaraju Kusumanchi wrote:
>
> Keep in mind that a lot of people using Linux systems cannot use rpms
> to install stuff.

You can unpack rpms without root access. For example, Intel distributes
their Fortran compiler as binary RPMs but you don't need root to
install. (Intel does do silly modifications afterwards but that's a
different story).

On the other hand, I think that the answer is probably that these are
transitory problems which will go away when gfortran replaces g77 in the
main gcc release: once that happens then you'd expect that the versions
of libraries like Lapack shipped with distros will be compiled with
gfortran so it'll be as easy as apt-get install lapack, or whatever your
distro does.

> Not everyone has root (or some level of sudo) access to do those sorts
> of things. And I'll wager that the number of people who do have that
> access is going to continue to decrease.
>
> For those cases compilable sources (or precompiled libraries/binaries)
> are the go.

As above. I think that packaging things up to install in the right
directories etc. is a Good Thing. The fall back is to expand the package
in your own directory. Of course if you don't have either root yourself,
or tech support who will install packages for you in a timely manner,
you are probably going to have long term problems anyway.

David

Charles Russell

2004-11-04, 3:57 am

"Jugoslav Dujic wrote

> CVF got better with the time, but (especially on a slow computer) it
> still suffers from
>

The DEC fortran 77 I had in mind was for the VMS operating system on the
VAX.

Scott Robert Ladd

2004-11-04, 3:58 pm

On Tue, 02 Nov 2004 16:13:44 +0100, Tobias Schlueter wrote:

>
> The move for adding MPI to gcc has only started a few w

s ago, so it's
> definitely not going to be something which will be there soon.

You may be confusing GOMP -- the effort to add OpenMP to gfortran -- with
MPI, which is a message-based, lossely-coupled form of data parallelism.
Support for MPI requires few changes in gfortran; HOWEVER, various MPI
implementations (esp. MPICH) need to be modified so they configure
correctly with gfortran. That's one of my little "spare time" projects.

--
Scott Robert Ladd
site: http://www.coyotegulch.com
blog: http://chaoticcoyote.blogspot.com

test

2004-11-04, 3:58 pm

Hi,

I think a straight forward installation process on Windows is important.

MPICH is important for me as I use fortran for simulation engines, and we
can see that using all those under utilized computers is important. Grid
computing will also be important in the near future.

Thom

"Scott Robert Ladd" <coyote@coyotegulch.com> wrote in message
news:pan.2004.10.29.14.27.45.650185@coyotegulch.com...
> Hi,
>
> gfortran (http://gcc.gnu.org/fortran) is the Fortran 95 compiler that will
> replace g77 in the forthcoming 4.0.0 version of the GNU Compiler
> Collection, GCC (http://gcc.gnu.org).
>
> Since gfortran is still in development, I know many people have not
> had a chance to use it. Snapshots are available from the GCC web site.
>
> While an official release is still several months away, I'm interested in
> knowing what Fortraners want from gfortran.
>
> Note that I have *no* official capacity in terms of gfortran, though I
> submit patches and do testing. For what it's worth, I'm a Fortran 95
> programmer who wants to see GCC be more useful to the Fortran community. A
> free compiler helps everyone, including commercial vendors, by making
> Fortran 95 readily available.
>
> I assume that compiling g77 code is a priority, as is correctly compiling
> Fortran 95.
>
> OpenMP won't be available until later, though progress is being made.
>
> How important is MPI -- MPICH in particular? I'm considering waiting to
> pursue this further until Open-MPI has its initial release in November.
>
> Thanks for considered opinions.
>
> --
> Scott Robert Ladd
> site: http://www.coyotegulch.com
> blog: http://chaoticcoyote.blogspot.com
>
>

Steven G. Johnson

2004-11-04, 8:56 pm

NNTP-Posting-Host: 18.87.0.80
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1099608639 9286 127.0.0.1 (4 Nov 2004 22:50:39 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 4 Nov 2004 22:50:39 +0000 (UTC)
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:124682

David Ham <d.a.ham@citg.tudelft.nl> wrote...
> On the other hand, I think that the answer is probably that these are
> transitory problems which will go away when gfortran replaces g77 in the
> main gcc release: once that happens then you'd expect that the versions
> of libraries like Lapack shipped with distros will be compiled with
> gfortran so it'll be as easy as apt-get install lapack, or whatever your
> distro does.

It shouldn't matter, anyway. As I understand it, gfortran is intended
to be binary-compatible with g77 for Fortran 77 code (although you may
also have to link -lg2c explicitly if you use gfortran with a g77
library).

SGJ

Roman Werpachowski

2004-11-17, 3:59 pm

On the Fri, 29 Oct 2004 18:41:08 +0000 (UTC), Dave Seaman wrote: