Possible bug in AT&T f77 compilers?

[Gregory G. Woodbury]

I just this week reported this bug to my vendor (Opus) and they confirmed
it with a note indicating that it might have been inherited from the AT&T
f77 compiler.

Symptoms:
	f77 -x prog.f
	prog.f contains a moderate size program (500 lines) that has lots
	of comments and blank lines. It also uses the f77 parameter
	statement to define some symbolic constants for certain
	subscript values representing data classes.

	The prog.x (cross-reference output file) misnumbers the
	appearance of most of the variables, and especially, the
	parameter names.  It was discovered specifically using the 
	'u' (no implicit variables) and 'U' (use exact case match)
	options on the f77 compiler, but has been seen in the simplest
	of cases as well.

	The problem seems to be related also to the use of blank lines.
	Removing blank lines causes the numbers to be slightly less off
	than with the blank lines.


Has anyone else observed this problem, or is it vendor specific?  It
occurs on all three of their CPU families (NS32xxx, CLIPPER and Mc88k)
and over 2 releases of the OS (r2.x and r3.x).

Interestingly, the tech support also noted that the fsplit command does *not*
properly deal with blanks in names.
-- 
Gregory G. Woodbury
Sysop/owner Wolves Den UNIX BBS, Durham NC
UUCP: ...dukcds!wolves!ggw   ...dukeac!wolves!ggw           [use the maps!]
Domain: ggw at cds.duke.edu  ggw at ac.duke.edu  ggw%wolves at ac.duke.edu
Phone: +1 919 493 1998 (Home)  +1 919 684 6126 (Work)
[The line eater is a boojum snark! ]           <standard disclaimers apply>