[gnu.gcc.bug] VMS GCC 1.30 bugs so far

eichelbe@NADC.ARPA (J. Eichelberger) (10/25/88)

System: VMS 4.5 on a VAX 8600.
GCC version used for compiling: The VMS boot .EXE's etc.
GCC version on which installation is being attempted: GCC 1.30.

The first problem I had was with CCCP.C:

Line 617: GCC_INCLUDE_DIR is not declared
Line 618: GPLUSPLUS_INCLUDE_DIR is not declared

(Note: These messages are not the exact ones, but if you look at the
code it's easy to understand what is meant.)

To fix this for now, I defined these and altered the code as needed so
they would be used.
---
The second problem:

VMS GCC 1.30 (actually, it's GCC-AS that's moaning, and I'm using the
VMS GCC boot version of GCC-AS.EXE) complained about a symbol
redefinition attempt:

$ gcc/debug/cc1_options="-mpcc-alignment" parse_tab.c

gcc_204000ca.s:5956: Ignoring attempt to re-define symbol

That was the error message.  I wrote a C program to print out line 5956
of the .S file.  Assuming the lines are defined as ending with '\n', my
program printed out line #5956 of the .S file.  I stopped the .S file
from being deleted after assembly of parse_output.c by removing the
relevant "$delete" commands from the GCC.COM file.  Line #5956 of the
.S file was:

.comm _yydebug,0

I hope I did this right and that it helps whoever works on finding the
fix for this bug.  Also, I found that this problem was no longer
reported if I went into parse_tab.c and removed the "#define YYDEBUG".
Apparently, this stops the code which causes this complaint from being
included.  I saw this same message with GCC 1.22, but I'm not sure the
line number was the same.  THIS MAY NOT BE MUCH OF A BUG since GCC 1.22
linked, contrary to the link problem you'll see below in which GCC 1.30
would not link.

HERE'S THE REAL MEAT OF THE PROBLEM:

No matter what I did, with YYDEBUG defined or not, I would always get
the following fatal error on the link for GCC-CC1:

$ link/nomap/exe=gcc-cc1 sys$input:/opt
!
!	"CC1" Linker options file
!
toplev,parse_tab,tree,print-tree,c-decl,c-typeck,stor-layout,fold-const,-
varasm,rtl,expr,stmt,expmed,explow,optabs,symout,dbxout,emit-rtl,insn-emit,-
jump,cse,loop,flow,stupid,combine,regclass,local-alloc,global-alloc,reload,-
reload1,insn-peep,final,recog,insn-recog,insn-extract,insn-output,obstack,-
integrate,-
gnu_cc:[000000]gcclib/lib,sys$share:vaxcrtl/lib
%LINK-F-ILLNAMELEN, Symbol  name length (0.) is illegal - not 1 to 31.
	in module PARSE_TAB file VAX$USERS:[JON.GCC-V130]PARSE_TAB.OBJ;1
$

I think this one is over my head.  Not in the understanding of it, but
in the cause of it.  I tried using the PARSE-TAB.C that came with the
release, the PARSE-TAB.C generated by passing PARSE.Y through the VMS
boot BISON, and the PARSE-TAB.C generated by passing PARSE.Y through
the newest BISON from prep.ai.mit.edu, retrieved via FTP.  Note that it
looks like there are two blanks between the words "Symbol" and "name"
in the first line of the link error message.  It looks like the symbol
name was null.  And the error message is really telling you that, too
(name length (0.)).

I can't get past this bug.

*** END OF MEAT ***

As a side note of these problems, it should be noted that the VMS .COM
files supplied for building GCC 1.30 look for PARSE.Y, PARSE_TAB.C,
DECL.C, and TYPECHECK.C.  These files are actually suppiled with the
names c-parse.y, c-parse.tab.c, c-decl.c, and c-typeck.c.   This is
true in the compressed tar file gcc.tar-1.30.Z from prep.ai.mit.edu.
What's true on tape distributions, I don't know.  I distinguish the
upper/lower case here because I FTP files down to my UNIX VAX and then
copy them over to my VMS VAX by some other means.  VMS people will
notice that you can't have a file name of C-PARSE.TAB.C - it contains
one too many "."'s.  I changed MAKE-CC1.COM to expect C-DECL.C and
C-TYPECK.C, and copied c-parse.y to PARSE.Y, and renamed (on UNIX
before the copy up to VMS) c-parse.tab.c to C-PARSE_TAB.C and then to
PARSE_TAB.C on VMS.  So to make a long story even longer, the names
should be reconciled or the installation instructions augmented.

Thanks for reading.  Hope to hear of some fix(es) soon.

	Jon Eichelberger
	eichelbe@nadc.arpa

KASHTAN@IU.AI.SRI.COM (David L. Kashtan) (10/25/88)

I think that I finally have enough of our startup company under control that
I can free up the time to deal with GCC 1.30 -- there have abviously been
some changes to the GCC environment since GCC 1.22 (the last VMS GCC I worked
on).  Give me about a week to get things together and I will post the results,
hopefully a notice of successful compilation, to this newsgroup.
David
-------