From:	SMTP%"RELAY-INFO-VAX@CRVAX.SRI.COM" 25-AUG-1993 07:52:08.21
To:	EVERHART
CC:	
Subj:	Re: VAX C optimization inconsistancy

From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.)
X-Newsgroups: comp.os.vms
Subject: Re: VAX C optimization inconsistancy
Message-Id: <1993Aug24.042344.6820@spcvxb.spc.edu>
Date: 24 Aug 93 04:23:44 EDT
Organization: St. Peter's College, US
Lines: 61
To: Info-VAX@kl.sri.com
X-Gateway-Source-Info: USENET

In article <1993Aug24.054125.22815@news.arc.nasa.gov>, madison@tgv.com (Matt Madison) writes:
> It's certainly within the realm of possibility.  Personally, I have
> had no such problems with VAX C.

  Oddly enough, I found one this past weekend. Nasty bug.

> It could be a compiler bug, or it could be a bug in your code.  Hard
> for anyone to tell without seeing the routine in question, and without
> knowing what version of VAX C you're talking about.  If you really suspect
> it's a compiler bug, you should probably report it to Digital.  They'll
> probably want to see the routine in question as well.

  DEC has said "no further development on VAX C or VAXCRTL. Use DEC C for
VAX/VMS instead". Good idea, except it isn't out yet (despite a number of
shipping DEC software packages being compiled with it).

  Earlier versions of VAX C (before V3.2-044) had horrible bugs, mostly in
function inlining. The bug I found goes away if you compile /OPT=NOINLINE.
In short, a return(0); inside a function (added to make DEC C and gcc happy)
was causing the VAX C compiler to miscompute entry masks *and* stack offsets
in unrelated functions that never even called the function that the return
was added to. Here's a piece of my diff file documenting the bug:

*** ckvtio.057	Sat Aug 21 18:50:43 1993
--- ckvtio.058	Sun Aug 22 03:50:31 1993
***************
*** 868,874 ****
--- 869,897 ----
      sprintf(msg, "%s: %s\n", s, buf);
      debug(F100,s,"",0);
      ermsg(msg);
+ 
+ /* This crock is necessary due to an inlining bug in the VAX C V3.2-044
+  * compiler. If it sees the return(0) below, it will generate incorrect
+  * entry masks for ttchk() and other routines. Whimper. And of course,
+  * DEC says "no further plans for development of VAX C or VAXCRTL - use
+  * DEC C for VAX/VMS instead. Good idea, except it isn't available yet!
+  *
+  * Here is a sample of the incorrectly generated code:
+  *
+  *	.entry	ttchk,^m<r2,r3,r4,r5,r6>	With return(0) in print_msg
+  *	movab	-536(sp),sp
+  *	movab	VMS_STATUS,r5
+  *	movab	DEBLOG,r6
+  *
+  *	.entry	ttchk,^m<r2,r3,r4,r5>		Without return(0) in print_msg
+  *	movab	-540(sp),sp
+  *	movab	VMS_STATUS,r4
+  *	movab	DEBLOG,r5
+  */
+ 
+ #if (!defined (VAXC) && !defined (__VAXC))
      return(0);
+ #endif	/* CROCK */
  }
  
  /*  S Y S I N I T  --  System-dependent program initialization.  */

	Terry Kennedy		Operations Manager, Academic Computing
	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
	terry@spcvxa.spc.edu	+1 201 915 9381