public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Henderson <rth@cygnus.com>
To: law@cygnus.com
Cc: "David S. Miller" <davem@jenolan.rutgers.edu>, egcs@cygnus.com
Subject: Re: Remaining generic bits from sparc64-linux merge
Date: Sat, 18 Oct 1997 11:32:00 -0000	[thread overview]
Message-ID: <19971018113450.53928@dot.cygnus.com> (raw)
In-Reply-To: <19375.877155402@hurl.cygnus.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~

  parent reply	other threads:[~1997-10-18 11:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-10-02 12:51 David S. Miller
1997-10-18  0:28 ` Jeffrey A Law
1997-10-17 23:21   ` David S. Miller
1997-10-18 11:32   ` Richard Henderson [this message]
1998-01-17 23:02 ` Jeffrey A Law
1998-01-17 23:08 ` Jeffrey A Law
1998-01-17 23:46 ` Jeffrey A Law
1998-01-23 16:56   ` David S. Miller
1998-01-28 23:25 ` Jeffrey A Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=19971018113450.53928@dot.cygnus.com \
    --to=rth@cygnus.com \
    --cc=davem@jenolan.rutgers.edu \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).