Re: g++-3 and g77-3 packages under setup-x86.exe

[LMH <lmh_users-groups at molconn dot com>]

Dima Pasechnik wrote:
> On 20 August 2013 03:13, LMH <lmh_users-groups@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