🚀 go-pugleaf

I wanted to enhance GNU CC to understand the C$INCLUDE logical
that the VMS C compiler knows about. Actually I wanted it to
work better than VMS C, so that it would understand things
like "../h/x.h".

I had recently received 1.30 and installed it on our Sun, so I
thought: silly to enhance 1.22 on VMS, I'll just get 1.30 going
under VMS then attack that.

First problem was unknown symbols GCC_INCLUDE_DIR and GPLUSPLUS_INCLUDE_DIR.
I just gave them an appropriate looking definition under ifdef VMS.
It seemed that they were only used for calculating a length of the
initial part of a file name.

The second problem was with the new bison. I know now that I should
have just copied the unix *.tab.c to *_TAB.C on VMS, but I didn't
know that then. So I got the new bison running, but it mysteriously
put a byte of all ones in the middle of the file. I had to make
the following change to output.c:

************
File C:[SMART.GNU.BISON]OUTPUT.C;2
 1281   	if( c!=EOF) putc(c, ftable);
 1282         c = getc(fpars);
******
File C:[SMART.GNU.BISON]OUTPUT.C;1
 1281   	putc(c, ftable);
 1282         c = getc(fpars);
************

I wonder why this isn't a problem in unix?

I might say that GCC gave an unhelpful error message for the bad
character. I tried compiling with VMS C and got the obvious error
message: illegal character on line etc.

There were various minor problems with the make*.com files. Source
files had changed their names, or new ones added.

I now had problems assembling the output from c-parse_tab.c. I
decided I'd better create the new assembler. GCC 1.22 had an immediate
problem in that there was no varargs.h -- I put the one from the 
1.30 distribution in the include directory. The make-gas.com file
also required error=as_fatal added to the /DEFINEs for xrealloc,
xmalloc, hash and vms.

But that didn't make any difference. So I looked at the .s file
and it seemed to be corrupted. So I decided that gcc 1.22 couldn't
handle it. So I went over to the Sun to make a 1.30 cross-compiler for
VMS. Now this isn't easy. There is just one #define VMS which means
both "this will execute under VMS" and "this will produce code for VMS".
So I changed all the #define VMS to #define VMSc wherever it seemed
to mean the former. This worked after I'd grabbed a few .H files
from the old VMS release, and used -I. This produced a .s file which 
the VMS gas almost liked. It didn't like:

	_yydebug:
		.long 0
	.comm _yydebug,0

It said that was "illegal attempt to redfine _yydebug". I put the .comm
line before the other 2 and it was happy. This is a bug somewhere in cc1.

Well that now all compiled and linked without error. But the resulting
compiler bombs out compiling a simple program. The next steps look
less trivial than the ones I have taken, and perhaps I should do some
real work :-(. Has anyone else had a go at this? I could try
using my 1.30 cross compiler for everything in case 1.22 is producing
bad code. Or make a debug version of the compiler and try to
understand what is going on.

Helppppppppppppp!

Bob Smart, CSIRO Division of Information Technology, Australia
           <smart@ditmelb.oz.au> or <smart%ditmelb.oz.au@uunet.uu.net>

P.S. The GCC 1.30 distribution is also missing lots of the bits necessary
to make a complete VMS distribution: VMS style .H files; the source
of GCC.EXE; the source of extra library routines in GCCLIB.OLB. I am
assuming these are unchanged from 1.22.