This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Always require a 64bit HWI
- From: Jeff Law <law at redhat dot com>
- To: Richard Biener <rguenther at suse dot de>
- Cc: gcc at gcc dot gnu dot org, dave dot anglin at bell dot net, gcc-patches at gcc dot gnu dot org
- Date: Wed, 30 Apr 2014 10:00:14 -0600
- Subject: Re: [PATCH][RFC] Always require a 64bit HWI
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1404291307480 dot 18709 at zhemvz dot fhfr dot qr> <5360029F dot 5020207 at redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1404301011020 dot 18709 at zhemvz dot fhfr dot qr>
On 04/30/14 02:16, Richard Biener wrote:
My recollection is that HP aCC supports long long, but I don't recall
when support for that was introduced. I'm really trying hard to forget
On Tue, 29 Apr 2014, Jeff Law wrote:
On 04/29/14 05:21, Richard Biener wrote:
The following patch forces the availability of a 64bit HWI
(without applying the cleanups that result from this). I propose
this exact patch for a short time to get those that are affected
and do not want to be affected scream.
But honestly I don't see any important host architecture that
not already requires a 64bit HWI.
Another concern is that the host compiler may not provide a
64bit type. I'm not sure that this is an issue nowadays
(even though C++98 doesn't have 'long long', so it's maybe
more an issue now with C++ than it was previously with
requiring C89). But given that it wasn't an issue for
the existing 64bit HWI requiring host archs it shouldn't
be an issue now.
The benefit of this change is obviously the cleanup that
can result from it - especially getting rid of code
generation dependences on the host (!need_64bit_hwi
doesn't mean we force a 32bit hwi). As followup
we can replace HOST_WIDE_INT and its friends with
int64_t variants and appear less confusing to
newcomers (and it's also less characters to type! yay!).
We'd still retain HOST_WIDEST_FAST_INT, and as Kenny
said elsewhere wide-int should internally operate on that,
not on the eventually slow int64_t. But that's a separate
So - any objections?
2014-04-29 Richard Biener <firstname.lastname@example.org>
* configure.ac: Always set need_64bit_hwint to yes.
* configure: Regenerated.
* config.gcc: Always set need_64bit_hwint to yes.
No objections. The requirement for 64 bit HWINT traces its origins back to
the MIPS R5900 target IIRC. It's probably well past the time when we should
just bite the bullet and make HWINT 64 bits across the board.
If the host compiler doesn't support 64-bit HWINT, then it seems to me the
host compiler can be used to bootstrap 4.9, which can then be used to
bootstrap more modern GCCs.
And like you I suspect it's really not going to be an issue in practice.
I realized I forgot to copy gcc-patches, so done now (patch copied
below again for reference).
I propose to apply the patch after the wide-int merge for a short
period of time and then followup with a patch to remove the
need_64bit_hwint code (I'll make sure to send that out for review
before applying this one).
Testing coverage for non-64bit hwi configs is really low these
days (I know of only 32bit hppa-*-* that is still built and
tested semi-regularly - Dave, I suppose the host compiler
has a 64bit long long type there, right?).
Plus, they can always start the bootstrapping process with GCC 4.9.