This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Remaining generic bits from sparc64-linux merge
- To: law at cygnus dot com
- Subject: Re: Remaining generic bits from sparc64-linux merge
- From: Richard Henderson <rth at cygnus dot com>
- Date: Sat, 18 Oct 1997 11:34:50 -0700
- Cc: "David S. Miller" <davem at jenolan dot rutgers dot edu>, egcs at cygnus dot com
- References: <199710021950.PAA04406@jenolan.rutgers.edu> <19375.877155402@hurl.cygnus.com>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Sat, Oct 18, 1997 at 12:16:42AM -0600, Jeffrey A Law wrote:
> > * tree.c (TYPE_HASH): Type of hash val is unsigned long.
> Why are you changing these variables from a HOST_WIDE_INT to
> unsigned longs?
To be more efficient when define HOST_WIDE_INT as long long for
crossing from a 32 to 64-bit platform. We later and off all but
the low 31 bits anyway.
> The inclusion of stdlib.h should be conditional on HAVE_STDLIB_H.
>
> You also can't just delete the atol extern -- I would think you
> would want to have autoconf determine if it's needed.
Reasonable points.
> I would advise against using atoq since I doubt it's a function we
> can really depend on.
It's been in the linux libcs for a while, but I now understand that
atoll is what made the ISO C 9x draft, so another autoconf test is
perhaps in order.
> Is %llx something you can really rely upon? I don't think so. Is there
> some way to handle this using standard format strings?
I suppose you could shift and mask, but there's no drop-in replacement
for the one argument other than %llx. Again, it is something that has
been in the Linux libc for years; Ulrich would know if it's been
sanctioned by the ISO draft.
Whether we really want to limit ourselves to generic functions here is
going to depend on how supported we want to make setting HOST_WIDE_INT
to long long. My reaction is you can only do it if your libc is
friendly enough. It shouldn't really have been needed at all, but it
was an expedient way to get around some bugs in the sparc64 support
at the time.
r~