DES@uno.bitnet (Dan Smith) (07/14/89)
I'm in the middle of a project that is going to require a c cross
compiler from VMess to a custom imbedded system based on a 68K processor.
I checked the gnu-cc stuff and it looks like a cross set up is relatively
easy to do with the correct combo of tm.h files and config.h's and the
right md and aux-output pieces.
Anyway, without getting into the cross part of things I decided to get
the latest gcc up on VMess also since I do a lot of work in C there also.
So I got the gcc-vms.tar.Z (dated Apr-5) and the gcc-1.35.tar.Z (dated Apr-26)
and started to build things. Everything went pretty smoothly until I hit
the c-parse pieces. And to answer the questions about bison before I get
a pile of mail, "Yes, I have the latest version of bison up on VMS." I
ported v1.01 before I got too involved in the gcc parts. So the parser
being generated appears to be good c code. The problem that I am running
into is that I get the following errors from gas when its assembling the
output of the cc1 phase:
baz-foo-xxxxxxx: Ignoring statement due to "Not enough operands"
baz-foo-xxxxxxx: Junk character 44.
baz-foo-xxxxxxx: Rest of line ignored. 1st junk character valued 114.
This happens a couple of times. From two different places in the c-parse
source. The routines in question are 'is_reserved_word' and 'yylex'. I
took a look at the .s file generated and it looks like cc1 is losing big
time and inserting non-printible garbage into the .s file. Here's the
extract from is_reserved_word. (I've converted the emacs display of the
non-prints so they will not get destroyed when this mail file gets pushed
thru the net)
.stabd 68,0,1339
.stabd 68,0,1340
LBB24:
.stabd 68,0,1374
cvtbl -1(r3)[r2],r1
movab _\261\255,r0 <- Note the interesting bytes!!!
addl3 r2,(r0)[r1],r1
cvtbl (r3),r2
addl2 (r0)[r2],r1
Anyway, the gcc-vms tar archive contained a v1.22 of gcc and it seems unable
to digest its newer version for bootstrapping purposes. Anybody out there
fixed this problem yet OR can tell me if I'm doing something silly (quite
possible). I've been able to vary the behavior by playing with the
definitions in the offending functions. If I remove the 'register' modifier
on any of the variable defs the symptoms change. They don't go away completely
but they do change. If I get desperate enough I guess I'll try to use the
VAX C compiler to bring up gnu-c but I'd rather avoid that painful experience
if at all possible.
Dan SmithDES@uno.bitnet (Dan Smith) (07/15/89)
I would like to thank everyone who sent helpful suggestions for my problem. I haven't fully tested it yet but I have done the first two phases of the build and everything looks clean. I still need to regen the gnulib parts and relink the compiler again but it looks much better now. Many thanks to Mike Albaugh (albaugh@dms.UUCP) for the fix/workaround for my problem. > > Try #defining inline to whitespace. No version of GCC prior to 1.32 >was bug-free in regard to inline. In particular, the wierd symbol you > When I get the pieces tested I'd be happy to bundle the .EXE's to save someone else the trauma (and the 20 min's CPU time for the gen on a 8600) if there is enough interest. Dan Smith -- Network Software Body @ UNO ps: I turned 'inline' back on after I got past the v1.22 boot phase. So the resulting compiler should be as fast as the optimizer can make it.