ravi@earth.ce.nwu.edu (Ravi Sinha) (02/03/91)
Thanks for the many replies I received. The general consensus is that there are bugs in it, but the overall performance is better than that of fortran v1.2. Bugs: o If an unformatted file of length >8k is created, the program should be created with -Bstatic option. o Because of a bug in the SunOS, use of TMPFS filesystems in v1.3 cause problems. Work-around is to apply the relevant OS patch. <khb@Eng.Sun.COM> o Function statements sometime generate bad code. <p554mve@mpirbn.mpifr-bonn.mpg.de> Feature: o Can not mix object codes of v1.2 and v1.3. General Comments: o Most people seemed to be quite pleased with v1.3.1 at patch level 2. The programs seem to run faster with this version of the compiler (will this change the Mflop rating of our computers? ;). o One can also run v1.2 with SunOS 4.1.x. One can just copy the old compiler to the new system; or reinstall, and when the installer fails, modify extract_unbundled in /usr/tmp/unbundled to include 4.1 in supported OS types, and run *this* installer script. o Sun is coming out with a new version of fortran compiler sometime in spring. Question to more knowledgeable readers: o While it is possible to combine old (OS4.0.3) c object codes with the new fortran, why is it not possible to combine v1.2 object codes? Or am I mistaken about compatibility with c object codes? Thanks to the following people for responses: roberto@bondi.phyast.pitt.edu (Roberto Gomez) john@ghostwheel.unm.edu (John Prentice) khb@Eng.Sun.COM (Keith Bierman fpgroup) Scott Lamson <lamson@el1.crd.ge.com> Dieterich Erwin <erwin%suncvt12.verfahrenstechnik.uni-stuttgart.de@RELAY.CS.NET> black@seismo.CSS.GOV (Mike Black) dgh@validgh.com (David G. Hough on validgh) rfinch@locke.water.ca.gov (Ralph Finch) opto!glen@gatech.edu (Glen Clark) p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) unocal!stssram@sunkist.West.Sun.COM (Bob Myers) --------------------------------------------------------------------- Ravi Sinha | As usual, the opinions here Northwestern University | are mine, and only mine. ravi@earth.ce.nwu.edu | Who'd want to claim these anyway?
john@ghostwheel.unm.edu (John Prentice) (02/04/91)
In article <3140@casbah.acns.nwu.edu> ravi@earth.ce.nwu.edu (Ravi Sinha) writes: >Thanks for the many replies I received. > >The general consensus is that there are bugs in it, but the overall >performance is better than that of fortran v1.2. > >Bugs: >o If an unformatted file of length >8k is created, the program should > be created with -Bstatic option. > >o Because of a bug in the SunOS, use of TMPFS filesystems in v1.3 > cause problems. Work-around is to apply the relevant OS patch. > <khb@Eng.Sun.COM> > >o Function statements sometime generate bad code. > <p554mve@mpirbn.mpifr-bonn.mpg.de> > >Feature: >o Can not mix object codes of v1.2 and v1.3. > >General Comments: >o Most people seemed to be quite pleased with v1.3.1 at patch level 2. > The programs seem to run faster with this version of the compiler (will > this change the Mflop rating of our computers? ;). > >o One can also run v1.2 with SunOS 4.1.x. One can just copy the old compiler > to the new system; or reinstall, and when the installer fails, modify > extract_unbundled in /usr/tmp/unbundled to include 4.1 in supported > OS types, and run *this* installer script. > >o Sun is coming out with a new version of fortran compiler sometime > in spring. > >Question to more knowledgeable readers: >o While it is possible to combine old (OS4.0.3) c object codes with the > new fortran, why is it not possible to combine v1.2 object codes? Or > am I mistaken about compatibility with c object codes? > >Thanks to the following people for responses: >roberto@bondi.phyast.pitt.edu (Roberto Gomez) >john@ghostwheel.unm.edu (John Prentice) >khb@Eng.Sun.COM (Keith Bierman fpgroup) >Scott Lamson <lamson@el1.crd.ge.com> >Dieterich Erwin > <erwin%suncvt12.verfahrenstechnik.uni-stuttgart.de@RELAY.CS.NET> >black@seismo.CSS.GOV (Mike Black) >dgh@validgh.com (David G. Hough on validgh) >rfinch@locke.water.ca.gov (Ralph Finch) >opto!glen@gatech.edu (Glen Clark) >p554mve@mpirbn.mpifr-bonn.mpg.de (Michael van Elst) >unocal!stssram@sunkist.West.Sun.COM (Bob Myers) > >--------------------------------------------------------------------- >Ravi Sinha | As usual, the opinions here >Northwestern University | are mine, and only mine. >ravi@earth.ce.nwu.edu | Who'd want to claim these anyway? -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA
john@ghostwheel.unm.edu (John Prentice) (02/04/91)
Whoops! Sorry about reposting the previous message. Something messed
up and my reply got trashed. What I intended to be posted was the
following comment. Concerning the -Bstatic bug, we have recently had
more problems with unformatted i/o. Specifically:
The following code bombed using Sun Fortran version 1.3 :
program test
parameter (imax=5000,jmax=20)
integer k(imax,jmax)
do 20 i=1,imax
do 10 j=1,jmax
k(i,j)=j
10 continue
20 continue
open (unit=1,file='test.dat',status='unknown',form='unformatted')
write (1) ((k(i,j),i=1,imax),j=1,jmax)
rewind 1
read (1) ((k(i,j),i=1,imax,j=1,jmax)
do 40 i=1,imax
do 30 j=1,jmax
if (k(i,j).ne.j) call abort
30 continue
40 continue
close (unit=1)
end
We compiled with:
f77 -Bstatic -o test test.f
and ran it. It failed the check in loop 30. HOWEVER, if you eliminate
the implied do in the read/write and just write/read the array (i.e.,
write (1) k ), it worked fine! We had other problems as well in trying
to compile a much more complicated code. We finally constructed work
arounds, but they are clumsy. By the way, without the -Bstatic, the
code bombs with a segmentation fault.
So, two questions. First, anyone see something unforgiveable that
I am doing with this code? Second, anyone else seen this problem
or know of a fix?
Thanks,
John
--
John K. Prentice john@unmfys.unm.edu (Internet)
Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA
Computational Physics Group, Amparo Corporation, Albuquerque, NM, USAkhb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/04/91)
The previous discussion was about v1.3.1 not v1.3; the reason for the
.1 release was to fix just such problems. Everyone who received v1.3
was supposed to received 1.3.1 .... did you not get it, or not install
it? Chiba is running 4.1.1.
btw: with patch2 linking static should not be necessary for large record
sizes.
Here is a runlog with f77v1.3.1 patch2
f77 -V john.f
version-id of "/home2/lang/SC0.0/SC0.0/f77pass1": SC0.0 f77 1.3.1 FCS 90/06/25
/home2/lang/SC0.0/SC0.0/f77pass1 "-P -cg87" john.f /tmp/f77pass1.10735.s.0.s /tmp/f77pass1.10735.i.1.s /tmp/f77pass1.10735.d.2.s
john.f:
MAIN test:
version-id of "/home2/lang/SC0.0/SC0.0/as": SC0.0 90/02/12
/home2/lang/SC0.0/SC0.0/as -o john.o -Q -cg87 /tmp/f77pass1.10735.s.0.s /tmp/f77pass1.10735.i.1.s /tmp/f77pass1.10735.d.2.s
rm /tmp/f77pass1.10735.s.0.s
rm /tmp/f77pass1.10735.i.1.s
rm /tmp/f77pass1.10735.d.2.s
version-id of "/bin/ld": Unknown
/bin/ld -dc -dp -e start -u _MAIN_ -X -o a.out /home2/lang/SC0.0/SC0.0/crt0.o /home2/lang/SC0.0/SC0.0/cg87/_crt1.o -L/home2/lang/SC0.0/SC0.0/cg87 -L/home2/lang/SC0.0/SC0.0 john.o -lF77 -lm -lc
rm john.o
chiba:/net/chiba/home2/khb>a.out
chiba:/net/chiba/home2/khb>
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043eloranta@tukki.jyu.fi (Jussi Eloranta) (02/05/91)
on Fortran 1.3.1 I've found the following problems:
1) Sometimes loader complains about mysterious 'mcount' symbol...
I checked the program and it didn't have a symbol with that name.
2) For example:
!72-col
WRITE(6,'(//10X,'' AN UNOPTIMIZABLE GEOMETRIC PARAMETER HAS'
1',/10X,'' BEEN MARKED FOR OPTIMIZATION. THIS IS A NON-FATAL ''
2,''ERROR'')')
Bombs since the line continuation occurs between two ' characters.
(works ok if I wrap one of ' chars to the other line).
This works on every single fortran compiler I've seen except sun fortran!
And I've also got very strange error messages from lines that don't even
exist! I don't remember these and don't know what the fix was... a friend
of mine fixed it. This has something to do with include files & parameter defs.
Also the 16 (?) KB record limit on write was reall great :-(
The program just dumped core if one tried to write a record > 16 KB...
but there is a patch to fix this problem.
And all these were found during 4 days. So there is probably more to come :-(
And they call it fortran compiler ...?
jussi
--
============================================================================
Jussi Eloranta Internet(/Bitnet):
University of Jyvaskyla, eloranta@tukki.jyu.fi
Finland [128.214.7.5]limes@ouroborous.Eng.Sun.COM (Greg Limes (Hacking in Night Mode)) (02/06/91)
In article <1991Feb04.013735.8220@ariel.unm.edu>, john@ghostwheel.unm.edu (John Prentice) writes: |> The following code bombed using Sun Fortran version 1.3 : |> write (1) ((k(i,j),i=1,imax),j=1,jmax) |> rewind 1 |> read (1) ((k(i,j),i=1,imax,j=1,jmax) I see a missing close parenthesis ... did you?
stead@beno.CSS.GOV (Richard Stead) (02/07/91)
In article <1991Feb4.194628.12615@tukki.jyu.fi>, eloranta@tukki.jyu.fi (Jussi Eloranta) writes: > > on Fortran 1.3.1 I've found the following problems: > > 1) Sometimes loader complains about mysterious 'mcount' symbol... > I checked the program and it didn't have a symbol with that name. [ one more specific complaint, and some vague complaints deleted ] I don't know about your other complaints, but this one is due to compiling some of your code for profiling, but linking it non-profiling. The mcount variable is used by the profiler. Compile and link your code either with or without profiling, but don't mix it. This is not specific to Fortran 1.3.1. > And all these were found during 4 days. So there is probably more to come :-( If they are all like this first one, the rest of us have nothing to worry about. > And they call it fortran compiler ...? No, the thing that uses mcount they call a profiler. Richard Stead Center for Seismic Studies stead@seismo.css.gov
winstead@faraday.ECE.CMU.EDU (Charles Holden Winstead) (02/08/91)
Hi,
I am a brand-spanking new reader of this bboard and I just wanted to ask
a couple of questions. I program in Fortran on Sun4's and Sparc stations,
and my questions are these:
1- Is Fortran on these Suns different than 'conventional' Fortran? i.e.
what do I have to look out for?
2- Is there a debugger that works? I've tried gdp and dbx and neither
can read the source code that fortran produces. The same program
compile dwith the same flags can be read on a DEC machine, so I'm
figuring it's a problem in Sun Fortran.
3- Every now and then I get an error that says Warning: IEEE floating
Point Error. Inexact Underflow. But it doesn't tell me where it
happened! I guess an anwer to 2 would also answer this.
Thank you for your help. I'm surrounded by c-hackers so I get no support
around here at all!
Charles Winstead
winstead@faraday.ece.cmu.edu
Carnegie Mellon khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (02/08/91)
In article <1991Feb8.023527.20806@fs7.ece.cmu.edu> winstead@faraday.ECE.CMU.EDU (Charles Holden Winstead) writes:
1- Is Fortran on these Suns different than 'conventional' Fortran? i.e.
what do I have to look out for?
It is a "standard" Unix fortran by parentage, with several years of
extensions. Most inspired by user requests for "vax-like" features,
sometimes others (Cray style pointers). See the Fortran User's Guide,
and Reference manuals.
2- Is there a debugger that works? I've tried gdp and dbx and neither
can read the source code that fortran produces. The same program
compile dwith the same flags can be read on a DEC machine, so I'm
figuring it's a problem in Sun Fortran.
Care to be more specific. dbx is far from perfect, but it can handle
many codes (the problem is that there are many that cause it grief ;<)
3- Every now and then I get an error that says Warning: IEEE floating
Point Error. Inexact Underflow. But it doesn't tell me where it
happened! I guess an anwer to 2 would also answer this.
That isn't what it sez. Inexact and Underflow are not errors. I'd bet
a beer that the message is something like
Warning: the following IEEE floating-point arithmetic
exceptions occurred in this program and were
never cleared:
Inexact; Underflow
The easiest reference is the Numerical Computation Guide. Should have
been in the box with your other Fortran manuals (the entire set
includes the reference, the user guide, dbx, source browser and ncg).
There are also excellent papers by Kahan (From UCB, turning award
winner for floating point work).
Exceptions are NOT errors. These two are particularly common. If you
expected your computation to be exact (see the ieee 754 spec for the
definition) you would WANT to know if it wasn't (most of us use fp
specifically because we are interested in approximations, else we'd be
tempted to used fixed point arithmetic ;> or symbolic techniques ;>).
Underflow means that some computation was very close to zero. So
close, that _some_ accuracy was lost (unlike non-ieee machines, or
-fnonstandard mode where the result would have been flushed to zero,
entailing a larger and completely silent lossage).
If you wish to never see the message, irrespective of events (not
recommended!, what if there had been overflow? illegal operand?) you
can do one of several things:
1) add a call to ieee_flags (man ieee_flags shoudl work)
clearing them all, or just the ones you don't care about.
Something like
ieeer= ieee_flags("clear","exception","all",out)
2) if you want to be truly evil, you could write your
own routine called ieee_retrospective, and link it in before
libm.
There is also a sort of hitchhikers guide to this stuff in the Fortran
User's guide, Chapter 10.
--
----------------------------------------------------------------
Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM
SMI 2550 Garcia 12-33 | (415 336 2648)
Mountain View, CA 94043john@ghostwheel.unm.edu (John Prentice) (02/08/91)
In article <1991Feb8.023527.20806@fs7.ece.cmu.edu> winstead@faraday.ECE.CMU.EDU (Charles Holden Winstead) writes: > > 1- Is Fortran on these Suns different than 'conventional' Fortran? i.e. > what do I have to look out for? > We have ported a large number of codes from PC's and Cray's to Sun Fortran. I have not found anything in Sun Fortran that has caused problems. It seems to include everything in the Fortran 77 standard. There are additions as well, specific to Sun. They only one we are making significant use of are the Fortran pointers (which work identically to how Cray uses them, something that came as a pleasant surprise to us). We use they in conjunction with calls to malloc (which Sun Fortran provides a nice Fortran interface to, saving you the trouble) to perform dynamic dimensioning. We use this feature extensively and have never had any problems. In general, I am fairly impressed by Sun Fortran. Our only complaint has been some bugs in 1.3.1 which have caused us problems, particularly of late. However, to be fair, we have used this compiler ALOT and only recently have we run into major problems. I am assured that these problems have been fixed in the new release, so that should not be regarded as a major stumbling block. John -- John K. Prentice john@unmfys.unm.edu (Internet) Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA