miller@rsmas.miami.edu (07/31/90)
Problem with the F77 compiler when -pfa option is used:
I am attempting to run a numerical model code under IRIX System V Release 3.3
on a SG Power Series and am having difficulties getting it to compile when
the -pfa option is turned on. The code compiles without error if I try
f77 -o programname programname.f
or
f77 -O3 -Olimit 1200 -o programname programname.f
but generates a "Fatal error in: /usr/lib/fcom - core dumped. Signal 139" if I
add the -pfa option to the above, viz.,
f77 -pfa -o programname programname.f
or
f77 -pfa -O3 -Olimit 1200 -o programname programname.f
Note that if I specify "-pfa list" rather than "-pfa", I do get the listing
showing what has or has not been flagged for concurrentization. So, the -pfa
option is doing at least part of its job but apparently fouls something up to
the point that fcom doesn't like it anymore.
Where can I find out what "signal 139" means? Anybody else had this problem?
Any suggestions?
-------------------------------------------------------------------------------
Jerry L. Miller INTERNET: miller@rsmas.miami.edu
Rosenstiel School of Marine and Atmospheric Science, University of Miami
Remember: "It's later now than it's ever been; however, vg'f zber yvxr
vg vf abj guna vg unf rire orra orsber."doelz@urz.unibas.ch (07/31/90)
In article <8450.26b44961@rsmas.miami.edu>, miller@rsmas.miami.edu writes: > Problem with the F77 compiler when -pfa option is used: .. > f77 -O3 -Olimit 1200 -o programname programname.f > > but generates a "Fatal error in: /usr/lib/fcom - core dumped. Signal 139" if I > add the -pfa option to the above, viz., .. > > Where can I find out what "signal 139" means? Anybody else had this problem? > Any suggestions? I get the same problem on an SGI 120 running 3.3 while trying to compile the ray tracer (E.Merritt) posted in this group recently. Mine dies in the compilation if specified f77 -O2 -Olimit 1400 program.f object.o 4Dgifts/iristools/limimage/libimage.a Fatal error in /usr/lib/uopt - core dumped Signal 139 *** Error code 1 The two errors don't need to be related. As far as I got informed, SGI knows that the highest bit is accidentially set and 139 is just 139 - 128 = 11 (segmentation violation) SIGSEV. Regards Reinhard
guy@auspex.auspex.com (Guy Harris) (08/01/90)
>Where can I find out what "signal 139" means?
"Memory fault - core dumped".
139 = 128+11. 11 means "memory fault" (11 is SIGSEGV, i.e. "memory
fault"); 128 means "core dumped". Stu Feldman apparently thought it was
good for your health to be obliged to dive into WAIT(2) to figure out
what various error codes mean (presumably he wrote the original "f77"
driver program, and definitely wrote the original "make", which also
rudely reports signals numerically). I think it's bad for your health,
which is why SunOS's "make" has, since 3.2 or so, reported those errors
more sanely.bron@bronze.wpd.sgi.com (Bron Campbell Nelson) (08/03/90)
In article <1990Jul31.082732.848@urz.unibas.ch>, doelz@urz.unibas.ch writes: > In article <8450.26b44961@rsmas.miami.edu>, miller@rsmas.miami.edu writes: > > Problem with the F77 compiler when -pfa option is used: > .. > > f77 -O3 -Olimit 1200 -o programname programname.f > > > > but generates a "Fatal error in: /usr/lib/fcom - core dumped. Signal 139" if I > > add the -pfa option to the above, viz., > .. > > > > Where can I find out what "signal 139" means? Anybody else had this problem? > > Any suggestions? > > As far as I got informed, SGI > knows that the highest bit is accidentially set and 139 is just 139 - 128 > = 11 (segmentation violation) SIGSEV. > Yes, this is correct. Basically it means the fcom bombed out. But then, you already knew that. J. Miller and I hashed this out over email during the last couple of days, and I believe I understand the problem and a possible workaround. The problem seems to be caused by the line-numbering directives that PFA inserts in order to keep track of what line in which file you are currently compiling. Somewhere along the way, the Fortran front end (fcom) got confused. Confused enough that it dumped core. A workaround is to suppress the insertion of the line-number directives by PFA by adding the "-lo=ol" option to the "-WK," option list. e.g. the command line f77 -c -O2 -pfa keep -WK,-lo=ol foo.f should clear it up. If you don't use cpp to do #include or macro processing, this can be combined with the -nocpp option. The drawback to this workaround is that any syntax error messages will refer to line numbers from the PFA transformed Fortran file (the ".m" file) and not the original source. Ditto for using dbx. Hope this is useful if someone else has this problem. -- Bron Campbell Nelson bron@sgi.com or possibly ..!ames!sgi!bron These statements are my own, not those of Silicon Graphics.
dixons%phvax.dnet@SMITHKLINE.COM (08/05/90)
I too have been bitten by the signal 139 bug in Irix 3.3 fortran altough
in my case, it had nothing to do with pfa. Specifically, I was trying to
compile the render3d program mentioned recently in this newgroup:
f77 -O3 -Olimit 1400 render.f local.o /usr/people/4Dgifts/iristools/
libimage/libimage.a -o render -lgl_s -lm
Fatal error in: /usr/lib/uopt - core dumped
Signal 139 *** Error code 1
From the recent messages in this group and other scuttlebutt I hear, there
seem to be a number of bugs in the 3.3 fortran release. I hope they will
be fixed in the real customer ship.
Scott Dixon (dixons@smithkline.com)