Dima Pasechnik wrote:
On 20 August 2013 03:13, LMH <lmh_users-gro...@molconn.com> wrote:
I would be happy to build gcc-3 myself, I'm just looking for some
documentation to get that done.
The fact the gcc-3/g77 are old means nothing to me. There are still millions
of lines of fortran77 code out there that are being used. There is just no
reason to spend years of man hours to update the code and result in new code
that gives the exact numerical answers as the old code. I already work 80,
and sometimes even 100 hours in a week developing new material. The less
time I have to spend on projects that already work as is, the better. The
last time I checked, important linux distros used in industry (Cent, Suse,
etc) all still included legacy gcc3 development support. If you think about
the investment in gcc3 based code that is out there, and the time that could
be required to port that to gcc4, keeping the legacy support makes allot of
sense.
When gcc4 first came out, I tried moving. I was able to get my code to
compile and link after making allot of changes to the header files, but I
got different numerical answers on my data for some cases. This is the real
bugbear.
gfortran is not considered a bugbear since about gcc 4.1. Its
developers are committed to considering
any standard Fortran 77 code that does not compile or
gives wrong results on gfortran a bug.
When you change compilers, everything has to be QC'd again. I tried
again with gcc4.3, and found again that many header files had changed and it
took quite a bit of work to get it to compile. When I did get it to work, I
now got the same numerical answers as with gcc3. This underscores some of
the issues that can happen when you change compilers, especially if the
compiler is a relatively new version. Imagine some of the disasters that
could have happened if I based research on the incorrect values from
software compiled under the early versions of gcc4!!! There have also been
allot of issues with folks trying to compile f77 code under gfortran.
In many cases, there is just no good reason to move compilers when you have
mature src code that has been optimized and QC'd for 30+ years. Why would
you want to put ANY time into maintaining such code?
I used to write a lot of Fortran 4 code back in 198*ies...
Should I demand an IBM-360 Fortran 4 compiler being
distributed? :-)
That is not a
rhetorical question, so if there are some good reasons to move to newer
versions of gcc, I would be interested in hearing the arguments. Putting in
time to revise code and end up with the identical assembler is not something
I am all that interested in.
Identical assembler? Come on, do you want your executables optimized for i486 ?
Then yes, you might want to us gcc3. :-)
Also it's obvious that most of Fortran 77 code had been developed not
on g77, but
using other compilers, mostly dead by now. After all, being a cross-compiler,
g77 is mostly a quick hack.
Dmitrii
Dmitrii, thank you for the thoughtful response. I really am looking for
information here. Allot of the fortran code that I use was actually
written in the 70's (on punch cards), so those systems are long gone as
well. I used Absoft for a while as well before moving to cygwin with
gcc. Since this code is so old, most of it is very, very, serial and
very simple (primitive data types, conditionals, and do loops). For such
simple code, I don't imagine that the assembler coming out of a compiler
today is all that different than it was a long time ago. Of course I
could be very wrong, and that is why I ask questions.
My only point about gfortran 4.0 was to illustrate that moving to a new
compiler can result in unforeseen problems. That can mean expending
resources to fix a self created problem. Just try go to get a corporate
IT director to migrate to a new OS version and you'll get a 10 hour
litany of everything that is likely to go wrong and how much it will
cost to fix it. I have associates at very big companies that are still
using Cent4. Why? Because everything they do works on Cent4, so why wade
into the mire of an upgrade? An OS is a different level of messy than a
compiler, but the principle is the same. The header files are never
going to change on gcc3. Everything I have that compiles on gcc3 now
will always compile on gcc3. I can't say the the same for gcc4. I do
have gcc4 installed and use it all the time. I just don't use it for
everything. I have done extensive testing and all of my older stuff runs
just as fast when built with gcc3 as when built with gcc4. If there
comes a point where gcc3 based apps will no longer be compatible with
more modern runtime components, or something like that, that that is
another story.
Stable code that does not require allot of maintenance is a beautiful
thing. Maybe it's time that I updated everything to gcc4, but I am
reluctant to spend a month or more to do that when it's not clear to me
what the benefits are. I know that g77 isn't the best compiler for
fortran. Some testing a while back showed that the Intel compiler gave
the best performance. I guess some of that may be because gcc3 is
compiling the f77 code as c. With the increase in hardware power,
performance differences don't seem as significant as they once were. At
least apps don't take 24 hours of CPU time to compile anymore. In all
cases, the fortran just lives as a subroutine called out of cpp, so
using gnu gcc/g++/g77 under cygwin was an easier option than trying to
find an ideal combination of other compilers.
LMH
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple