Re: fix for 64bit uncleanliness in cp/class.c

[Geoff Keating <geoffk at cygnus dot com>]

> Date: Sat, 22 Jan 2000 13:43:01 -0500 (EST)
> From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> Cc: gcc-patches@gcc.gnu.org, law@cygnus.com, rth@cygnus.com
> 
>  > From: Geoff Keating <geoffk@cygnus.com>
>  > 
>  > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
>  > 
>  > >  > From: Brad Lucier <lucier@math.purdue.edu>
>  > >  > 
>  > >  > There still seems to be a problem with today's mainline; perhaps I wasn't
>  > >  > clear that there were two distinct problems.
>  > >  > 
>  > >  > ../../../gcc/cp/class.c: In function `dump_class_hierarchy':
>  > >  > ../../../gcc/cp/class.c:6304: warning: int format, different type arg (arg 7)
>  > >  > 
>  > >  > 	* class.c (dump_class_hierarchy): Use %ld to print a HOST_WIDE_INT
>  > >  > 
>  > >  > RCS file: RCS/class.c,v
>  > >  > retrieving revision 1.1
>  > >  > diff -c -r1.1 class.c
>  > >  > *** class.c     2000/01/21 17:28:59     1.1
>  > >  > --- class.c     2000/01/21 17:41:26
>  > >  > ***************
>  > >  > *** 6297,6303 ****
>  > >  >   {
>  > >  >     int i;
>  > >  >   
>  > >  > !   fprintf (stderr, "%*s0x%lx (%s) %d %s\n", indent, "",
>  > >  >            (unsigned long) binfo,
>  > >  >            type_as_string (binfo, TS_PLAIN),
>  > >  >            TREE_INT_CST_LOW (BINFO_OFFSET (binfo)),
>  > >  > --- 6297,6303 ----
>  > >  >   {
>  > >  >     int i;
>  > >  >   
>  > >  > !   fprintf (stderr, "%*s0x%lx (%s) %ld %s\n", indent, "",
>  > >  >            (unsigned long) binfo,
>  > >  >            type_as_string (binfo, TS_PLAIN),
>  > >  >            TREE_INT_CST_LOW (BINFO_OFFSET (binfo)),
>  > >  > 
>  > >  > 
>  > > 
>  > > 
>  > > Not all platforms make HOST_WIDE_INT a long, some make it an int.  The
>  > > correct thing to do here is to use %ld and cast the arg to (long).
>  > 
>  > No.  Some platforms make HOST_WIDE_INT 'long long'.
>  > 
>  > You instead want to use the macros designed for this purpose in
>  > hwint.h:
>  > 
>  > HOST_WIDE_INT a;
>  > 
>  > printf ("a is " HOST_WIDE_INT_PRINT_HEX ", really!\n", a);
>  > 
>  > -- 
>  > - Geoffrey Keating <geoffk@cygnus.com>
> 
> 
> No, the above form uses ANSI string concatenation which is not allowed
> since we must support K&R bootstraps.  (And it was decided to enforce
> this even for the language subdirs which are only compiled by gcc
> since we want code to be movable between parts of the compiler without
> a hassle.)
> 
> If you decide to use the HOST_WIDE_INT_PRINT_* macros, which you're
> right is probably safest, then you must split the print statements
> like thus:
> 
> printf ("a is ");
> printf (HOST_WIDE_INT_PRINT_HEX, a);
> printf (", really!\n");

You are right.

> However IMHO it is usually simpler to just cast the value to the
> largest type HOST_WIDE_INT can be and use the matching format
> specifier.

You mean, intmax_t?  I think that's not very portable yet.

> As to your second point about HOST_WIDE_INT being a "long long", I'm
> pretty sure its never supposed to be so.  IIRC, the reasons are that
> long long is much slower than long, (and IMO, a double "ll" integer
> specifier is not portable.  Though its hard to imagine someone cross
> compiling from a platform which doesn't support it to one that does,
> nevertheless, we try to avoid it.)

It's expected that if HOST_WIDE_INT is 'long long', then the platform
supports 'long long', including in printf()...

I have not noticed that making HOST_WIDE_INT 'long long' makes the
compiler much slower.  I'd be very surprised if this was so.  The
compiler doesn't spend most of its time doing constant folding.

> Now we have HOST_WIDEST_INT (widest, not wide) for cases where 64 bits
> is absolutely required.  I don't have the URLs handy, but this all was
> discussed around the time I fixed cccp/cpp to handle 64 bit LL
> constants.  (IIRC, due to a testcase you provided. :-)
> 
> Hmm, I see xm-alpha-interix.h and alpha/xm-vms.h actually set
> HOST_WIDE_INT to "long long".  This supports your claim, but IMHO, I
> think they might be wrong to do it this way.  Can anyone shed light on
> these config files?

At present, gcc cannot handle (absolutely cannot, not just
won't-optimize) integer values with more than twice the number of bits
in a HOST_WIDE_INT.  So the only way to implement 128-bit values in
GCC on a 32-bit platform is to set HOST_WIDE_INT to be 64 bits long,
and if that means using multiword arithmetic then that's unfortunate
but necessary.

'long long' on Alpha is, IIRC, 128 bits long.

It also helps when cross-compiling from a 32-bit host to a 64-bit
target, even if it doesn't need 128-bit values, because various bits
of GCC don't optimize values that don't fit in a HOST_WIDE_INT---of
course, those bits are usually broken in other ways anyway, because
they tend to expect that you can do things like add two CONST_INT
values together with '+' and get a CONST_INT result, so it may
actually be better for stability not to do this :-).

-- 
- Geoffrey Keating <geoffk@cygnus.com>