Path: utzoo!telly!ddsw1!mcdchg!rutgers!tut.cis.ohio-state.edu!UUNET.UU.NET!munnari!ditmelb.oz.au!SMART
From: munnari!ditmelb.oz.au!SMART@UUNET.UU.NET (Robert Smart)
Newsgroups: gnu.gcc.bug
Subject: Porting GNU CC 1.30 to VMS
Message-ID: <8811250243.AA27364@uunet.UU.NET>
Date: 25 Nov 88 03:01:00 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 80

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
            or 

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.