Problem with -pfa option in f77 compile command

[Bron Campbell Nelson]

In article <1990Jul31.082732.848 at urz.unibas.ch>, doelz at urz.unibas.ch writes:
> In article <8450.26b44961 at rsmas.miami.edu>, miller at 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 at sgi.com  or possibly  ..!ames!sgi!bron
These statements are my own, not those of Silicon Graphics.