SRWMSPW@windy.dsir.govt.nz (07/04/90)
Whats the worst fortran compiler in the whole wide world? ANSWER: THE DEC F77 ULTRIX RISC COMPILER In 20 years of scientific computing i have experienced some bad ones (IBM H extended springs to mind) but never never anything this bad. Does anybody know if later versions (we seem to be stuck with 1.0) solve any of the many problems.
axt654@csc.anu.oz (07/05/90)
In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: > > Whats the worst fortran compiler in the whole wide world? > > ANSWER: THE DEC F77 ULTRIX RISC COMPILER > > In 20 years of scientific computing i have experienced some > bad ones (IBM H extended springs to mind) but never never anything this bad. > > Does anybody know if later versions (we seem to be stuck with 1.0) solve > any of the many problems. So what's wrong with it? I'm using it on a DECStation 3100 and it works fine, some minor bugs but nothing major.
SRWMSPW@windy.dsir.govt.nz (07/05/90)
In article <2330.26922b0b@csc.anu.oz>, axt654@csc.anu.oz writes: > In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: >> >> Whats the worst fortran compiler in the whole wide world? >> >> ANSWER: THE DEC F77 ULTRIX RISC COMPILER >> >> In 20 years of scientific computing i have experienced some >> bad ones (IBM H extended springs to mind) but never never anything this bad. >> >> Does anybody know if later versions (we seem to be stuck with 1.0) solve >> any of the many problems. > > > So what's wrong with it? > I'm using it on a DECStation 3100 and it works fine, some minor bugs > but nothing major. Where to begin? Try using namelists to read in common block variables Try using -O2 or -O3 . . . I would say 50 % of the programs I have tried to compile have failed in some way due to compiler bugs. These problems were all due to compiler bugs not the use of non standard fortran. For example compiling some routines from the harwell library failed becuase the compiler appeared to forget what IF meant. Compiling each routine separately worked fine.
acar@ee.umr.edu (07/06/90)
In article <2330.26922b0b@csc.anu.oz> you write: |>In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: |>> |>> Whats the worst fortran compiler in the whole wide world? |>> |>> ANSWER: THE DEC F77 ULTRIX RISC COMPILER |>> |>> In 20 years of scientific computing i have experienced some |>> bad ones (IBM H extended springs to mind) but never never anything this bad. |>> |>> Does anybody know if later versions (we seem to be stuck with 1.0) solve |>> any of the many problems. |> |> |>So what's wrong with it? |>I'm using it on a DECStation 3100 and it works fine, some minor bugs |>but nothing major. Me too. Moreover, it is about three times faster than the compiler we have on a Sparcstation 1. ********************************************************************* L. Acar --- Univ. of Missouri-Rolla ********************************************************************* -- ****************************************************************** L. Acar --- Univ. of Missouri-Rolla
umapy03@sunb.cc.ic.ac.uk (K. Hampel Ext 6918 Supvsr D.Vvedensky) (07/06/90)
In article <2330.26922b0b@csc.anu.oz> axt654@csc.anu.oz writes: >In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: >> >> Whats the worst fortran compiler in the whole wide world? >> >> ANSWER: THE DEC F77 ULTRIX RISC COMPILER >> >> In 20 years of scientific computing i have experienced some >> bad ones (IBM H extended springs to mind) but never never anything this bad. >> >> Does anybody know if later versions (we seem to be stuck with 1.0) solve >> any of the many problems. > > >So what's wrong with it? >I'm using it on a DECStation 3100 and it works fine, some minor bugs >but nothing major. Well, we're now onto version 2.1 in MIPS parlance (i.e. that is what is reported by 'f77 -V prog.f'). This is NOT the same number as in the ULTRIX documentation. This now seems to be a working (and fast) version of the f77 compiler. So far it has worked very well with all our codes. Kris Hampel, Solid State Theory Group. kris@sst.ph.ic.ac.uk uk.ac.ic.ph.sst (JaNET)
SRWMSPW@windy.dsir.govt.nz (07/06/90)
0In article <1168@umriscc.isc.umr.edu>, acar@ee.umr.edu writes: > In article <2330.26922b0b@csc.anu.oz> you write: > |>In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: > |>> > |>> Whats the worst fortran compiler in the whole wide world? > |>> > |>> ANSWER: THE DEC F77 ULTRIX RISC COMPILER > |>> > |>> In 20 years of scientific computing i have experienced some > |>> bad ones (IBM H extended springs to mind) but never never anything this bad. > |>> > |>> Does anybody know if later versions (we seem to be stuck with 1.0) solve > |>> any of the many problems. > |> > |> > |>So what's wrong with it? > |>I'm using it on a DECStation 3100 and it works fine, some minor bugs > |>but nothing major. > > Me too. Moreover, it is about three times faster than the compiler we > have on a Sparcstation 1. > > ********************************************************************* > > L. Acar --- Univ. of Missouri-Rolla > > ********************************************************************* > -- > ****************************************************************** > > L. Acar --- Univ. of Missouri-Rolla I have had a large response to my original posting most of it disagreeing (some more strongly than others ) with my posting. It would seem that the early versions of the compiler did indeed have a number of bugs but these are fixed at version 2. many people felt that becuase namelists were not part of the fortran 77 standard then i had no right to expect them to work. I still feel that if a compiler claims to support an extension such as namelists then I have ever right to expect them to work. I would rather a compiler recognised what was too hard for it to optimize and did not try. Stephen White
mccalpin@vax1.acs.udel.EDU (John D Mccalpin) (07/06/90)
In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: > Whats the worst fortran compiler in the whole wide world? > ANSWER: THE DEC F77 ULTRIX RISC COMPILER > Does anybody know if later versions (we seem to be stuck with 1.0) solve > any of the many problems. Your problem is that you have an early release. The compiler is based on the MIPS f77 compiler, which is actually quite good. Unfortunately, their early releases had some nasty bugs, and DEC added more when they ported it to Ultrix. The bugs were of the nature that they did not touch many/most programs, so many users were quite happy with the compiler. Most of the trouble was with the lesser-used features fof Fortran. I got bit with bugs in ENTRY and alternate RETURN features. Get the new compiler and you will be much happier. Of course, if you want the *latest* releases, you will have to buy a MIPS computer system, but DEC (and SGI) are generally only a few months behind MIPS in their revisions of f77. -- John D. McCalpin mccalpin@vax1.udel.edu Assistant Professor mccalpin@delocn.udel.edu College of Marine Studies, U. Del. mccalpin@scri1.scri.fsu.edu
duty@murdu.oz (Duty Programmer) (07/09/90)
In article <16521@windy.dsir.govt.nz> SRWMSPW@windy.dsir.govt.nz writes: >In article <2330.26922b0b@csc.anu.oz>, axt654@csc.anu.oz writes: >> In article <16430@windy.dsir.govt.nz>, SRWMSPW@windy.dsir.govt.nz writes: >>> >>> Whats the worst fortran compiler in the whole wide world? >>> >>> ANSWER: THE DEC F77 ULTRIX RISC COMPILER >>> >>> In 20 years of scientific computing i have experienced some >>> bad ones (IBM H extended springs to mind) but never never anything this bad. > . >I would say 50 % of the programs I have tried to compile have failed in >some way due to compiler bugs. > That sounds pretty impressive. My vote is the Data General AOS/VS fortran compiler. Admittedly most of the problems arise from using AOS/VS multitasking (similar to threads in Mach), but in five years the DG boys have failed time after time to eradicate these. In fact, we have had to leave just about every release of the compiler on the system, because you never know what new bugs will have been introduced in the new releases! You often have to compile different parts of the code with different versions of the compiler in order to get the whole program to work! Certain F77 file I/O statements (BACKSPACE, ENDFILE, INQUIRE) had to be eradicated from the code to stop programs from bombing completely. Curiously, the AOS/VS C compiler appears to be completely bug-free. Richard Brown -- ========================================================================== Richard Brown | E-mail: pbrown@munda.ph.unimelb.EDU.AU School of Physics | Phone : +61 3 344 5081 University of Melbourne | Fax : +61 3 344 5104 Parkville Victoria AUSTRALIA 3052 | Telex : AA35185
bbesler@vela.acs.oakland.edu (Brent Besler) (07/18/90)
I have done alot of Fortran programming work with Silicon Graphics(a MIPS RSIC chip) based machine. On both a Dec Ultrix machine like the 3100 or 5820 and the SG machines many code will mysteriously start working if you compile them with the -static option.
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (07/18/90)
In article <2107@vela.acs.oakland.edu> bbesler@vela.acs.oakland.edu (Brent Besler) writes: >I have done alot of Fortran programming work with Silicon Graphics(a MIPS >RSIC chip) based machine. On both a Dec Ultrix machine like the 3100 or >5820 and the SG machines many code will mysteriously start working if >you compile them with the -static option. This isn't mysterious at all, it means you have bugs. Two common ways to trigger this are to assume local variables are zero without initializing them, and to assume local variables keep their values across different calls without having a SAVE statement. A program that runs on some machines isn't necessarily a correct program. -- "Perhaps I'm commenting a bit cynically, but I think I'm qualified to." - Dan Bernstein
khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (07/18/90)
In article <2107@vela.acs.oakland.edu> bbesler@vela.acs.oakland.edu (Brent Besler) writes:
... 5820 and the SG machines many code will mysteriously start working if
you compile them with the -static option.
For this class of codes, nothing mysterious, at least not in most
cases. X3.9-1978 allows local storage to be just that. Local. Not
saved from call to call. Thus one _can_ get it from the stack, or a
heap or whatever.
But many codes expect:
1) unitialized variables to be zero
2) values to be preserved across calls
Many will dispute #2, especially on their own codes .... but it does
happen. A popular (in some circles) matrix output routine I once
inherited control of, exhibited both!
.... lots of stuff
M=MOLD
.....
MOLD=M
First time through it was zero (by magic). After that, it correctly
"remembered" the column number from the last run. Which was what was desired.
This was only discovered after a port to a high performance box....
The way to write standard compliant code which does this is
integer MOLD ! well OK, I'm using mixed case ;> and !
data MOLD/0/
save MOLD
M=MOLD ... etc.
Interestingly enough, some compilers seem to think that save and data
are mutually exclusive. I have never found text in 3.9-1978 to justify
that ... compilers that can't accept both, do tend to treat DATA
variables as saved so the functionality is present.
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault | MTS --Only my work belongs to Sun* khb@chiba.Eng.Sun.COM
I Voted for Bill & | Advanced Languages/Floating Point Group (415 336 2648)
Opus<khb@eng.sun.com> "When the going gets Weird .. the Weird turn PRO"burley@world.std.com (James C Burley) (07/19/90)
In article <KHB.90Jul17174619@chiba.Eng.Sun.COM> khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes:
Interestingly enough, some compilers seem to think that save and data
are mutually exclusive. I have never found text in 3.9-1978 to justify
that ... compilers that can't accept both, do tend to treat DATA
variables as saved so the functionality is present.
Apparently the F77 standard (3.9-1978) didn't require DATA'd variables to
be treated as having the SAVE attribute also, though it certainly (as you
point out) didn't disallow both DATA and SAVE for a variable (i.e. they are
not mutually exclusive).
But the F90 standard is saying "If you DATA a variable, you implicitly SAVE it
(and may explicitly SAVE it also), even though F77 didn't specify this", and
it says so in the list of differences at the F77 level between F77 and F90.
Presumably the usefulness of having a DATA but not a SAVE attribute for a
variable would be that, while the variable has the same storage attributes
(i.e. not on the stack) as if it both DATA and SAVE were specified, the lack
of a SAVE attribute could allow optimization to decide not to write a new
value of the variable back to the memory location from a register before
exiting the routine. F90 probably decided the situations in which this
might actually be useful were too few and far between to require such a thing
of standard-conforming compilers (though I'm putting words in their mouths
here!). And/or they discovered that so many programs were written assuming
DATA implied SAVE that they should standardize it.