[gnu.gcc.bug] GCC 1.34 + Xenix 2.3.1 = "yow! my brain hurts!"

daveb@gonzo.UUCP (Dave Brower) (03/25/89)

I've been trying to get gcc 1.34 up on Xenix 2.3.1 using the Microsoft
compiler which is what seems available.  Has anyone done this
sucessfully?  The weak of heart probably ought to avoid this exercise.

So far I've run into the following problems, unfortunately reconstructed
from memory rather than notes.

1.  syms.h is missing.  I turned off the SDB output and it wasn't missed.

2.  One file needed all the buffer arguments to fwrite() cast to (char *)
    because the compiler refused to accept structure addresses.  (Sounds
    like a broken cc to me...).

3.  The compiler absolutely chokes on long lines, like those produced
    by macro expansion.  I used gcc -E to run the gnu cpp over the
    source of expflow.c (sp?), reload.c and reload1.c, and then ran
    the recently posted indent(1) over the output to fold long lines.

    Now, ANSI only says the compiler has to take 509 char lines, but 
    methinks someone in Wash. took this a bit too literally.

4.  One nasty expression in reload.c, containing nested ?: operators
    inside multi-dimensional [][] inside an if() drove MSC bonkers.
    Creating some explicit temp variables and figuring the result of
    the if bit by bit solved the problem.

5.  The stage1 build, using the MSC compiled gnu programs exits compiling
    the first program, with exit code 1.

I'm not all that enthused by the hassle this has been.  1.34 dropped
pretty much right onto a Sun/3, Sun/4, VAX and a 3b1.  Compared to those
other boxes this has been grim, indeed.  Maybe things'll be a little
better in the morning.  

If I *do* get it to work, I'll post patches. I'm clueless what to do
about the long line problem for other people, though.  There really
isn't much you can do but fold the long lines after preprocessing.

-dB
-- 
"I came here for an argument." "Oh.  This is getting hit on the head"
{sun,mtxinu,amdahl,hoptoad}!rtech!gonzo!daveb	daveb@gonzo.uucp