[geeks] Re: [rescue] need IRIX CD (C Front End CD)

[Jonathan C. Patschke]

On Wed, 27 Mar 2002, Mike Katchabaw wrote:
> Perhaps you know the answer to this question.

Disclaimer: I am not an SGI expert.  I've been using SGIs for about 6
years now, and like their products, as I can generally get them to do what
I want with an acceptable amount of heartache.  I've also been dealing
with this set of problems for a couple of years now.  I've got a little
bit of clue[0], but I may be totally wrong on some points.  Feel free to
correct me. :)

> Does the IRIX 6.5 distribution come with the C compiler, or is it only
> available separately?  (If so, where?)

IRIX 6.5 proper does not ship with a compiler.  It ships with an
assembler, a linker, and all the libraries and maintenance tools you'll
need to make programs--except for the compiler.  It ships with patches to
MIPSpro 7.2 that fix problems with targeting 6.5, should you be upgrading
from 6.2 through 6.4, and be running MIPSpro 7.2.

Compilers are sold on a per-workstation, per-language basis for $800[1]
from SGI.  So, if you want to use MIPSpro C and C++, you need to hand SGI
$1600, or you need to find a friend with the CDs and a workaround for the
gripe-messages.

On some high-end systems, the compiler frontends are bundled with (but not
licensed with--there's a separate license card) the OS, increasing the
confusion as to whether or not a compiler ships with IRIX 6.5.

> and library CDs but I cannot locate the compiler itself.  I have heard
> that it is there somewhere, but I have no idea.

This is largely misunderstood.  Everything is there except for the C, C++,
F77, and F90 "frontends" which are just the parsers and optimizers for
the languages.  In short, there's enough there to rebuild the kernel, but
not enough to use for development in anything other than MIPS assembly,
which is certainly fun, if impractical.

> I'm not too worried about the bitch message as I just want to test the

It's about 38 lines long, and it goes to stderr along with any
warnings/errors. It makes build-debugging pretty difficult.  But, it's
easy to circumvent.

> compiler out against gcc (which allegedly is buggy under IRIX 6.5.x) to
> see if I should purchase the compiler for work, or stick with gcc.

Here's the story on GCC.  It sucks pretty much equally (that is to say, "a
lot") everywhere.  It doesn't optimize very well, and it has some
-serious- code generation problems on 64-bit platforms.  It's only saving
grace is that it -is- everywhere, so most-everyone uses it.

The problem with GCC and IRIX actually goes all the way back to IRIX 6.0
(or whatever version introduced the N32 ABI), and is due to the fact that
the GCC maintainers didn't read the MIPS ABI specification very well.  
So, the problem isn't specific to IRIX, but to -any- conformant N32
OS/library on the MIPS R4000 and later CPUs.

The exact problem occurs when GCC codes a function call that passes a
structure via a register instead of via the stack.  Since any structure
passed by register must be smaller than 64 bits (otherwise, it wouldn't
fit), it must be padded to fill the register.  GCC aligns the struct with
the wrong side of the register.  So, when the function receives struct,
it'll be looking at the wrong end of the register and will receive garbage
(padding plus a tiny bit of data) instead of data.

...Unless it, too, was compiled with GCC.  GCC is completely consistent
within itself, but disagrees with MIPSpro and the MIPS ABI.  So, code
compiled with GCC won't work when register-passing a structure to MIPSpro
code, or vice-versa.

Fortunately, this bug isn't triggered too often, as most structures are
more than 8 bytes long.  Unfortunately, inet_ntoa(), which is used in
every single piece of networking code, triggers it.  Many of the
semaphores functions, and libXpm functions also trigger it.  Which is just
about enough to annoy any relatively complicated program (PostgreSQL
being the most recent example I have).  PERL also wants to get built with
MIPSpro, or it will segfault with clockwork regularity during certain
types of I/O.

There's an easy workaround to inet_ntoa()--write your own, it's an easy
function.  And, if you compile your own libXpm (and, of course, libX11),
that's not a problem, either.  If you need semaphores, though, your'e SOL,
as they're controlled via syscalls.

> Any help you can give is greatly appreciated!

GCC is okay, as far as it goes.  I haven't recently had any huge problems
with it under 6.5.  Earlier versions were a complete pain to get running
under 6.2.  If you can deal with the hassle of rebuilding -every- freely
available library you're going to link against (which I do, anyway), and
running a GCC-set of binaries alongside an SGI-set of binaries
(/usr/freeware vs. /usr on my systems), and don't mind plopping in the
code for inet_ntoa() for every network daemon/client you build, it's not
-too- bad.

In fact, I still use it more than MIPSpro C because there's so much crappy
code out there that won't past MIPSpro's thorough ANSI/sanity checks.
But, my code passed through MIPSpro, so I can be well-assured that it'll
pass through gcc -Wall -pedantic -ansi with no problems.

For what it's worth, the bug is not fixed in GCC 3 (yet), but there are
workarounds for the inet_ functions in SGI's precompiled GCC 2.95.3
distribution.  It's quite possible that the GCC team won't fix the bug,
simply because then linking code from older and newer versions of GCC
would exhibit the same problem.

Rumor has it that GCC has the same problem when targeting SPARC64 on
Solaris, but I don't have any more information that rumors.  If it's true,
maybe people would stop bashing SGI[2] and lay the blame where it's due.

HTH,

--Jonathan
[0] Obtained elsewhere, but it's mine now.  Muahaha!
[1] Astroglide sold separately.  Batteries not included.  Pray to whatever
    deity you believe in that your motherboard never goes south.  Support
    costs extra.  You get to buy it all again if you upgrade to a
    different workstation.  Microsoft only wishes their licensing was as
    evil.  That being said, it's F-ing -awesome- software, especially the
    APO, which I wish I had (along with a computer that could take
    advantage of it).
[2] Over this issue, anyway.