CVS-19981209: Patch for "unsigned HOST_WIDE_INT" on Solaris2.6
Jeffrey A Law
law@cygnus.com
Fri Dec 11 02:10:00 GMT 1998
In message < 13935.39643.570262.15767@sls5gj.stgl.sel.alcatel.de >you write:
> #ifndef HOST_WIDE_INT
> # if HAVE_INTTYPES_H
> # include <inttypes.h>
> # define HOST_WIDE_INT intmax_t
> # else
>
> The system's <inttypes.h> then defines a
>
> typedef int64_t intmax_t;
>
> This is, what gcc is moaning about:
>
> register unsigned HOST_WIDE_INT i;
>
> which becomes after pre-processing:
>
> register unsigned intmax_t i;
>
> which is simply not allowed.
>
> As Dave Brolley suggested in a different email, we should get rid of
> the #if HAVE_INTTYPES_H stuff and use the plain old #define way
> instead. I've extended this to avoid defining HOST_WIDE_INT redundantly
> in several files (cpplib.h, machmode.h, probably others), but to provide
> only *one* definition in e.g. "system.h". If we agree on that, I'll
> send a new patch.
So does anyone know why we've bothered with inttypes.h to start with?
I agree, it seems rather silly to have two different ways to get
HOST_WIDE_INT defined, and as a result of the differences, code which
works in one context fails in another context (as we've seed for the
"unsigned HOST_WIDE_INT" case).
Paul -- do you remember the original motivation behind adding uses of
inttypes.h?
jeff
More information about the Gcc-patches
mailing list