Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

g95 versus gfortran


Dear Group,

A couple of months ago I have installed g95 on my home PC together with "photran" (in eclipse) and msys. I am quite happy with the
setup as it allows me do at home most of what I do at work and in some cases even more. Note that at work I work with Sun stuff
(OS, compiler, etc. etc.). However, the software I develop should be able to run on most platforms (Sun, Linux, AIX, XP, and even
Mac).

After intalling g95 I have also run into gfortran. I have been looking at the web sites of both projects but to me I do not
understand this apparent "double" development of GNU (or at least GNU-like) fortran compilers.

For me this has raised the following questions.
1) Why are two compilers being developed.
2) What are the differences between the compilers.
3) Which compiler should a fortran program developer (like me) use and why.

Many thanks in advance for any clarifications/hints/tips anyone can give me!

Cheers,
Tim

Tim Springer wrote:
> For me this has raised the following questions.
> 1) Why are two compilers being developed.

http://gcc.gnu.org/wiki/TheOtherGCCBasedFortranCompiler

> 2) What are the differences between the compilers.

others can answer this better than me.

> 3) Which compiler should a fortran program developer (like me) use and why.

why not use both?

In short, squabbling.

> Cheers,
> Tim

--

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

On Apr 9, 4:33 am, "Tim Springer" <Tim.Sprin@solenix.ch> wrote:

> Dear Group,

> A couple of months ago I have installed g95 on my home PC together with "photran" (in eclipse) and msys. I am quite happy with the
> setup as it allows me do at home most of what I do at work and in some cases even more. Note that at work I work with Sun stuff
> (OS, compiler, etc. etc.). However, the software I develop should be able to run on most platforms (Sun, Linux, AIX, XP, and even
> Mac).

> After intalling g95 I have also run into gfortran. I have been looking at the web sites of both projects but to me I do not
> understand this apparent "double" development of GNU (or at least GNU-like) fortran compilers.

> For me this has raised the following questions.
> 1) Why are two compilers being developed.

That is a political question. I think the primary developer of g95,
who started the project to build a free Fortran 95 compiler, felt that
he could be more productive if he controlled the code base. Before and
after the split, he has been extremely productive. He gets bug reports
and suggestions from lots of people and acts on them quickly.

> 2) What are the differences between the compilers.

Gfortran should compile all Fortran 77 code. G95 does not "promise" to
compile Fortran 77 code that is not also Fortran 95 code (most is).
Gfortran produces faster programs than g95, but there are more bugs in
Gfortran. I think g95 has more features of Fortran 2003.

> 3) Which compiler should a fortran program developer (like me) use and why.

I use g95 primarily but sometimes use gfortran when a program is done,
to increase speed. Gfortran does reject some invalid code that g95
accepts -- see for example the thread "array operations on non-
conforming arrays -- do compilers catch them?"
http://groups.google.com/group/comp.lang.fortran/browse_frm/thread/2a...
. Therefore it is helpful in debugging.

Tim Springer <Tim.Sprin@solenix.ch> wrote:
> For me this has raised the following questions.
> 1) Why are two compilers [gfortran and g95] being developed.

Personal disagreements among the developers. Or, as Gary described it,
squabbling. I won't go into the details, and I probably don't even fully
understand them all - personal disagreements are sometimes that way. I
would caution you against taking a description from either "side" as
being accurate.

I have people who I regard as personal friends on both "sides". It is
unfortunate when two people, both of whom I think of as friends, don't
get along with each other. But it happens; this certainly isn't the only
such case. I think it best for me not to "take sides" in those cases.

> 2) What are the differences between the compilers.

That's more than I can go into (or know off-hand).

> 3) Which compiler should a fortran program developer (like me) use and why.

Well, that's geting into the "taking sides" bit. I've generally had
better luck with g95, but that could change, and other people have
contrary experiences. As Tom Micevski notes, you can use, or at least
try, both, as they are free.

There are even advantages to using multiple compilers in development. It
helps detect accidental compiler dependencies in your code. If anything,
these two compilers are not dissimillar enough to be ideal for that, but
still, two is often better than one.

They usually aren't particularly difficult to install; if you do find
one of them difficult to install on your particular system, that can be
a perfectly valid part of your evaluation. (There have been times when I
found that the pre-built binary packages for my system were not working
on my system of choice, which was a signiicant bar to me.)

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

Tim Springer wrote:
> 3) Which compiler should a fortran program developer (like me) use and
> why.

My primary compiler is gfortran instead of g95. My reasoning is as follows
(others will correct me if I am wrong).

I am primarily a user and my aim is to write good Fortran 90/95 code. So all
I want is some compiler that just works without any fiddling. I also do not
care about other versions of fortran. If I have just wanted a fortran 90/95
compiler, then any of gfortran, g95 would be sufficient. However, I also
need various libraries such as lapack, mpich, fftw etc.,

Debian Linux (my OS) includes all these libraries by default. All these
libraries are built by using gcc and gfortran. Debian also includes
gfortran by default. So, if I go with gfortran, rest assured, I need not
spend time on compiling and installing libraries etc., However, if I go
with g95, I have to do all this tedious tasks myself.

That being said, I usually compile my codes with multiple compilers (absoft,
gfortran, g95 etc.,) as that usually exposes some bugs that I was
previously unaware of.

hth
raju

--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/

Tim Springer wrote:
> For me this has raised the following questions.
> 1) Why are two compilers being developed.
> 2) What are the differences between the compilers.

To add something to what others have said: There are two philosophies
about how to build a Fortran compiler on top of the GCC middle- and
back-end.  One is to take a stable snapshot of the GCC parts, ideally
from a well-debugged non-experimental branch, so that the Fortran parts
are the only new things and one doesn't have to deal with updating the
Fortran code to deal with changes in the other part of the compiler.
The other philosophy is to base one's work on the current GCC
development branch, which means that one gets all the recent GCC
improvements, but also has to keep dealing with all of the changes those
incur, and occasionally deal with new bugs that get introduced.

G95 is an example of the first philosophy.  I believe it's currently
based on GCC 4.0.4, which is at this point very stable and reasonably
well debugged.  This means that all the time that Andy puts into it gets
spent on Fortran improvements and on fixing Fortran bugs, and his
"development" version is essentially a finished product.

GFortran is an example of the second philosophy.  It's even included as
part of the official GCC source tree, which means that changes to GCC
are immediately and automatically part of GFortran.  For users, this
means that if you want the latest GFortran front end, you also get the
latest GCC back-end, with whatever improvements and/or bugs and
unfinishedness it might have.

Note that this also means that there are effectively three current
GFortran versions, just like there are three current GCC versions.
Version 4.1.2 is the current release branch, which at this point is
quite stable, but has a fairly incomplete Fortran compiler.  Version
4.2.0 is the upcoming release branch (hopefully coming out within a few
weeks), which should also be pretty stable once released, and has an
essentially complete Fortran compiler.  Version 4.3.0 is the development
branch, which is essentially in an "alpha" state -- it isn't always
stable but it has the latest Fortran bits on it.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Tim Springer schreef:

> For me this has raised the following questions.
> 1) Why are two compilers being developed.

OK. Boring history.

It started with just one compiler. Development of G95 was started in
early 2000 by Andy Vaught, but he was reluctant to include the work
from other people. At one point there were five different projects
working on some version of G95, working on different bits missing in
Andy's "official" G95 tree.

It also became clear in private conversations between Andy and others
(including myself) that Andy did not intend to follow the rules and
guidelines necessary to make G95 an integrated part of GCC. He wished
to instead keep it as a separate front end, like it is now (and like
e.g. the G77 and Ada front ends for GCC were for a long time). Andy
believed this approach would result in a more stable and usable
compiler for end users.

Other people wanted to integrate the front end with GCC for various
reasons, like not having to keep track of changes in GCC. If someone
wants to change the GCC interface between the code generator and the
front ends, it is his/her responsibility to keep all front end
workings. So the maintenance burden is spread out more if your front
end is an integral part of GCC, and as front end developers you don't
have to worry about the interface anymore.

The original G95 project (i.e. with more people than just Andy trying
to contribute) eventually fell apart in early 2003 when Paul Brook and
I forked G95. We imported the fork into the GCC code base a few months
later. This front end is now known as gfortran.

So the compilers have a common ancestor, but the way they are related
to GNU/GCC is different.

Basically you see Andy was "right" because he got a more stable
compiler out to end users more quickly, and that the gfortran fork was
"right" because gfortran benefits more quickly from improvements to
the GCC code generators.  More on that below...

> 2) What are the differences between the compilers.

There are *lots* of differences, so I can only give some impressions
here:

The general impression seems to be that G95 conforms better to the
standard and has fewer bugs than gfortran. I know of at least some
points where G95 can compile that gfortran still cannot (e.g.
equivalence with an initializer). On the other hand, I also have
examples where gfortran compiles code while G95 choques on it.
(Gfortran uses the bug tracking system of gcc.gnu.org. If you run into
some problems, please report them there ;-)

Gfortran generally produces faster code than G95, because more
attention has been given to gfortran for producing easy-to-optimize
intermediate code, and because gfortran is based on a code generation
engine that is more recent than the one that G95 uses.

Gfortran has support for OpenMP and it tends to have fewer problems
with legacy g77 code. G95 has support for more Fortran 2003 features
than gfortran does.

> 3) Which compiler should a fortran program developer (like me) use and why.

Use both if you can, and use even more compilers if you have access to
them! ;-)
If you use more than one compiler, your code will be more portable
because different compilers can complain about different non-standard
code issues.

Gr.
Steven

On Apr 10, 1:03 pm, stevenb.@gmail.com wrote:

<snip>

> On the other hand, I also have
> examples where gfortran compiles code while G95 choques on it.

Can you post some examples or email them to me? I will relay them to
Andy if you have not reported them.

Thanks to you and Brooks Moses for your illuminating messages.

> Can you post some examples or email them to me? I will relay them to
> Andy if you have not reported them.

I think most of them are already available, some of them in the GCC
bugzilla open bugs and others in the gfortran testsuite (included in the
GCC source tree).

--
FX

On Apr 10, 1:15 pm, "FX" <coud@alussinan.org> wrote:

> > Can you post some examples or email them to me? I will relay them to
> > Andy if you have not reported them.

> I think most of them are already available, some of them in the GCC
> bugzilla open bugs and others in the gfortran testsuite (included in the
> GCC source tree).

> --
> FX

Yes, but if someone has a list of the SUBSET of codes that reveal bugs
in gfortran AND g95 bugs, that would speed the debugging of g95. When
I look in GCC bugzilla I rarely see a mention of whether the bug also
exists in g95 -- nor do I expect to.

Brooks Moses wrote:
> GFortran is an example of the second philosophy.  It's even included as
> part of the official GCC source tree, which means that changes to GCC
> are immediately and automatically part of GFortran.  For users, this
> means that if you want the latest GFortran front end, you also get the
> latest GCC back-end, with whatever improvements and/or bugs and
> unfinishedness it might have.

Ah, you probably weren't there when Craig Burley and a couple of good
men tried to maintain a g77 *outside* the GCC mainline (i.e., before
August 1997).  It was very hard, prone to mistakes, and disbelieve
(Should I really trust your updates to the middle/backend that you say
are necessary to get some decent performance for code compiled by g77 ?).

Consequently, *at that time*, g77 wasn't included in Free Software
Distributions (like GNU/Linux distro's).  That therefore meant that it
was much less used than would have been possible (not many people
install their self-compiled compilers).

Therefore, when g95 started, I more or less assumed that it would lead
automatically to some point in time where the development would be
sufficiently "complete" to include it into the GCC repository, as g77
was (by that time), and would be worked on from there.

I was very much surprised that Andy somehow was reluctant to ever decide
that the time was ripe, or even under which criteria the time would be
ripe for inclusion in GCC (with hindsight I now understand, and indeed,
as you say, it's basically because of the two different development
philosophies).

To give an example why I think that *my* philosophy is right (hah !),
consider the matrix transformation optimization that Razya Ladelsky from
the IBM Haifa Lab has developed.  The moment this is in I'm going to
throw the following at it:

       SUBROUTINE SUB(A, B, N, M)
       DIMENSION A(N, M), B(N, M)
       DO I = 1, N
          DO J = 1, M
             A(I, J) = B(I, J)
          ENDDO
       ENDDO
       END

This currently doesn't vectorize - it should when the transformation is
in (and turned on).  If it still doesn't vectorize, I can throw this
code at her and ask her why.

Now try to imagine you are using g95, and want the same optimization,
and it doesn't work.  The hard part is to prove to the GCC crowd that it
isn't something special g95 is doing that prevents the optimization
(I've been there with g77 a decade ago).  You can't blame the GCC
developers - they're far too busy to debug a problem with an unknown (to
them, because outside the repository) front end.

[ OK, this was long, but there *is* a rationale behind having the
   Fortran front end inside the GCC repository. ]

--
Toon Moene - e-mail: t@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran:
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html

> Yes, but if someone has a list of the SUBSET of codes that reveal bugs
> in gfortran AND g95 bugs, that would speed the debugging of g95.

Of course.

On a related note: anybody willing to start an open-source,
as-exhaustive-as-possible testing framework of the Fortran standard? ;-)

--
FX

On Apr 10, 5:04 pm, "FX" <coud@alussinan.org> wrote:

> > Yes, but if someone has a list of the SUBSET of codes that reveal bugs
> > in gfortran AND g95 bugs, that would speed the debugging of g95.

> Of course.

> On a related note: anybody willing to start an open-source,
> as-exhaustive-as-possible testing framework of the Fortran standard? ;-)

Would you plan to test Fortran 2003 from the beginning or test Fortran
95 and think about F2003 later?
In article <1176240115.435840.278@r34g2000cwr.googlegroups.com>,

Beliavsky <beliav@aol.com> wrote:
>On Apr 10, 5:04 pm, "FX" <coud@alussinan.org> wrote:
>> > Yes, but if someone has a list of the SUBSET of codes that reveal bugs
>> > in gfortran AND g95 bugs, that would speed the debugging of g95.

>> Of course.

>> On a related note: anybody willing to start an open-source,
>> as-exhaustive-as-possible testing framework of the Fortran standard? ;-)

>Would you plan to test Fortran 2003 from the beginning or test Fortran
>95 and think about F2003 later?

For each Fortran dialect you also need 2 kinds of test program:
(1) valid Fortran that at least one compiler won't compile,
(2) Fortran invalid because it violates a Constraint in the standard,
but at least one compiler fails to detect the error.

You may also want to collect examples of
(3) valid Fortran that gives a run-time error but shouldn't,
(4) Fortran that ought to give a run-time error but doesn't.

And if you're sending bug reports to compiler developers, all 4 kinds
of program should be as brief as possible.

-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john.har@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Toon Moene wrote:
> Brooks Moses wrote:
>> GFortran is an example of the second philosophy.  It's even included as
>> part of the official GCC source tree, which means that changes to GCC
>> are immediately and automatically part of GFortran.  For users, this
>> means that if you want the latest GFortran front end, you also get the
>> latest GCC back-end, with whatever improvements and/or bugs and
>> unfinishedness it might have.

> Ah, you probably weren't there when Craig Burley and a couple of good
> men tried to maintain a g77 *outside* the GCC mainline (i.e., before
> August 1997).  It was very hard, prone to mistakes, and disbelieve
> (Should I really trust your updates to the middle/backend that you say
> are necessary to get some decent performance for code compiled by g77 ?).

Indeed -- I think my initial experience with g77 was somewhere in early
fall of 1998.

> [ OK, this was long, but there *is* a rationale behind having the
>    Fortran front end inside the GCC repository. ]

Agreed; if my post implied that there wasn't, then I did not write what
I intended!  Regardless, I appreciate the historical perspective; I
hadn't realized that g77 was ever outside the GCC tree, and in
particular hadn't realized that it was so new when I started using it.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Dear Group,

Many thanks to all who have replied! I have taken the general advice
received to use as many compilers as possible!

I now installed gfortran next to the g95. In the same process I also got a
30-day evaluation version of the Intel compiler, it seems that for Linux the
Intel compiler is free whereas for Windows one has to buy it, bummer have to
go get a Linux box in due time I guess. At work I use the Sun studio
compiler so I can now run 4 compilers on my code. I guess I should also
install gfotran and g95 at work on the Sun so I can use them there as well.
I assume that they are both supposed to work on the Sun?

Many thanks!

Cheers,
Tim

"Tim Springer" <Tim.Sprin@solenix.ch> schrieb im Newsbeitrag news:evctob$r48$01$1@news.t-online.com...

> I assume that they are both supposed to work on the Sun?

You assume right. Binary packages of gfortran for sparc-solaris and
x86-solaris are not built any more due to very low demand (only a few
downloads over a year period, IIRC), but they be built from source
(instructions can be found at http://gcc.gnu.org/install/ ; if you have
any problem doing it, send a mail to fort@gcc.gnu.org or
gcc-h@gcc.gnu.org).

For g95, there appears to be up-to-date binaries for sparc-solaris and
6-months old binaries for x86-solaris. (http://ftp.g95.org/)

--
FX

On Apr 12, 4:44 am, "Tim Springer" <Tim.Sprin@solenix.ch> wrote:

> Dear Group,

> Many thanks to all who have replied! I have taken the general advice
> received to use as many compilers as possible!

> I now installed gfortran next to the g95. In the same process I also got a
> 30-day evaluation version of the Intel compiler, it seems that for Linux the
> Intel compiler is free whereas for Windows one has to buy it, bummer have to
> go get a Linux box in due time I guess.

The Intel compiler for Linux is free only for non-commercial use,
which is defined on the Intel Fortran web site at
http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm .

Tim Springer wrote:
> Dear Group,

> Many thanks to all who have replied! I have taken the general advice
> received to use as many compilers as possible!

> I now installed gfortran next to the g95. In the same process I also got a
> 30-day evaluation version of the Intel compiler, it seems that for Linux
> the
> Intel compiler is free whereas for Windows one has to buy it, bummer
> have to
> go get a Linux box in due time I guess.

On the other hand, if everybody bought a Linux box and only used the
free version, people who bought the Windows version would no longer be
subsidizing its development and how long would it be around then?

<snip>

>> Cheers,
>> Tim

--

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

> On the other hand, if everybody bought a Linux box and only used the
> free version, people who bought the Windows version would no longer be
> subsidizing its development and how long would it be around then?

For both Windows and Linux, it's not available gratis for commercial use.
Given that the Intel definition of commercial use is rather broad (which
is OK to me, but not universally understood AFAICT), I think not so many
people actually use their compiler under the non commercial licencing.
(According to
http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm,
commercial use includes teaching and academic research)

PS: there's also a point in the above page that asks: "If I use the
non-commercial product to build my product, can I open source it?" It
does not provide an answer, but merely a link to a GPL FAQ. I've read the
FAQ, and could not determine what the answer to the question is. Can
someone help me understand this? and yes, I know that NHIAL (noone here
is a lawyer), so you can skip the disclaimer part in your answer :)

--
FX

Hello,

Gary Scott wrote:

<snip>

> On the other hand, if everybody bought a Linux box and only used the
> free version, people who bought the Windows version would no longer be
> subsidizing its development and how long would it be around then?

OTOH, gcc and g++ seem to have done reasonably well, and I would guess
they are as responsible as anything for the success of C/C++
as languages.  Early in the history of PCs, Pascal was the commercially
favored language, IIRC.

That is, being free does not preclude continued development, nor
wide availability, nor enough quality to be useful.

Some have claimed that lack of a free Fortran 90/95 seriously hurt
Fortran, and we see here "Fortran's dead without a free f03
as of today" posts with fair frequency.

--

Dan Nagle
Purple Sage Computing Solutions, Inc.

On Apr 12, 8:56 am, "FX" <coud@alussinan.org> wrote:

Quoting the Intel site,

"Q. If I use the non-commercial product to build my product, can I
open source it?
A. The FAQ for GNU GPL has information related to this question.
Please refer to the GNU website "Frequently Asked Questions about the
GNU GPL" at: http://www.gnu.org/licenses/gpl-faq.html For further
clarification, please contact the Free Software Foundation at: <snip>

Q. I'm developing a product that I provide for free. However, I do
charge for supporting this product. Can I use the noncommercial
products for developing this product?
A. No. Even though the product you develop is free, it is part of an
overall commercial offering."

The first question makes little sense as written. Using the Intel
compiler does not give them rights over your source code, and the
Intel compiler is not GPL'ed anyway. I think the question is whether
one can distribute executables created with a compiler under a non-
commercial license. Looking at the second question and answer, I think
the answer to this is yes, as long as one is not compensated for
distributing or supporting the program.

FX wrote:
> For both Windows and Linux, it's not available gratis for commercial use.
> Given that the Intel definition of commercial use is rather broad (which
> is OK to me, but not universally understood AFAICT), I think not so many
> people actually use their compiler under the non commercial licencing.
> (According to
> http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm,
> commercial use includes teaching and academic research)

For those academic purposes, specific licenses are available.
On Apr 12, 8:25 am, Dan Nagle <danna@verizon.net> wrote:

Then we get into issues such as general quality of open source code.
I've looked at a lot and not been too impressed.  On the other hand,
I've not had the opportunity to look at proprietary vendor code.  I
can't help believe though that on average, people who's actual job is
to write compilers, and who have a successfully marketed, profitable
product, will have incentive to write quality, efficient, competitive
code.  I think though, that Intel would not have much incentive to
continue writing high quality software if it was unprofitable.  Yes,
I'm certain that there are plenty of anti-profit-incentive, hacker-
types that will contribute their spare time to writing software that
they give away.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc