[4bsd-f77 #30] min/max intrinsic functions sometimes cause f77 to die

[4bsd-f77 at utah-cs.UUCP]

From: Donn Seeley <donn at utah-cs.arpa>

Subject: min/max intrinsic functions sometimes cause f77 to die
Index:	usr.bin/f77/src/f77pass1/putpcc.c 4.2BSD

Description:
	F77 occasionally craps out on minimum/maximum intrinsic
	functions in special circumstances.  The circumstances occur
	when the function is called in a subscript expression and the
	optimizer is enabled.  I found this bug in an ancient bug
	report that Craig Leres sent to Ralph Campbell and which
	Ralph had forwarded to me but I'd managed to misplace.

Repeat-By:
	Try to compile the following program with the optimizer on
	(program from Craig Leres):

	----------------------------------------------------------------
	      subroutine fail(str, i, j)
	      integer str(100)
	      integer i, j
	      str(min0(i,j)) = 0
	      return
	      end
	----------------------------------------------------------------

	The compiler will die with the following message:

	----------------------------------------------------------------
	fail.f:
	   fail:
	Compiler error line 4 of leres/fail.f: Impossible tag 4 in routine frtemp

	compiler error.
	----------------------------------------------------------------

Fix:
	The problem is that the routine which handles intermediate code
	output for min/max intrinsics, putmnmx(), has bungled its
	temporary storage management.  putmnmx() gets its temporaries
	from the mkaltemp() allocator, but attempts to free them with
	frtemp(), which is used to reallocate temporaries obtained from
	the mktemp() allocator.  There are a couple reasons why the
	problem only shows up in the absurd circumstances mentioned
	above: when the optimizer is off, the temporaries returned by
	mkaltemp() are conveniently the same type as those returned by
	mktemp(); and there is a bug farther upstream which prevents
	min/max operations in subscripts from being expanded before
	optimization like they normally are.  When the latter harmless
	bug is fixed, this bug will go away anyway, but in the
	interests of good coding here are the fixes to putmnmx() in
	putpcc.c that prevent the original problem:

	----------------------------------------------------------------
	*** /tmp/,RCSt1007987	Tue Jul 24 19:37:20 1984
	--- putpcc.c	Tue Jul 24 19:08:40 1984
	***************
	*** 1488,1495
		}
	  
	  putcomma(ncomma, type, NO);
	! frtemp(sp);
	! frtemp(tp);
	  frchain( &p0 );
	  }
	  

	--- 1492,1499 -----
		}
	  
	  putcomma(ncomma, type, NO);
	! frexpr(sp);
	! frexpr(tp);
	  frchain( &p0 );
	  }
	  
	----------------------------------------------------------------

Donn Seeley    University of Utah CS Dept    donn at utah-cs.arpa
40 46' 6"N 111 50' 34"W    (801) 581-5668    decvax!utah-cs!donn