CVS-19981209: Patch for "unsigned HOST_WIDE_INT" on Solaris2.6

[Richard Kenner]

      > It's a trivial change, and any errors will be caught at compile-time.
      > (If the spelling is unsigned_HOST_WIDE_INT we needn't even change the
      > layout.  :-)

    You're missing the point.  You can't make those changes because you
    have zero control over that code.

Now *I'm* missing something.  From what I understand, EGCS has already made
changes that require work on front ends it doesn't control.  Why should
this one be any different?

    Such changes will also make it impossible for existing non integrated
    frontends or backends to work with the compiler.

As would other changes made in the past, such as using system.h and I think
some changes in tree.h, and probably others.

    If you think this isn't an issue, look at GNAT, which hasn't had a
    public release in about 15 months.

The GNAT 3.11 situation has nothing whatsover to do with GCC: the
delay has mostly been due to GDB issues on NT.

    I don't see that the benefit of using inttypes.h to provide a type for
    HOST_WIDE_INT outweighs the lossages associated with such a change.
    Especially when we can get the same net result with a less intrusive
    change.

I'm sort of in the middle on this.  I certainly agree that
incompatible changes are bad, but changes that can be fixed with
one-character fixes and which show up as errors compiling the front
end are more benign than many other changes.

As the one who implemented HOST_WIDE_INT in the first place, I think I
can say that it has always been a real mess without hurting anybody's
feelings.  Anything we can do to clean up this mess without causing
major incompatibilities are things I'm in favor of.