This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC] Always require a 64bit HWI
- From: Richard Biener <rguenther at suse dot de>
- To: Jeff Law <law at redhat dot com>
- 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:16:25 +0200 (CEST)
- 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>
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
> > issue.
> > So - any objections?
> > Thanks,
> > Richard.
> > 2014-04-29 Richard Biener <firstname.lastname@example.org>
> > libcpp/
> > * 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?).
2014-04-29 Richard Biener <email@example.com>
* configure.ac: Always set need_64bit_hwint to yes.
* configure: Regenerated.
* config.gcc: Always set need_64bit_hwint to yes.
--- libcpp/configure.ac (revision 209890)
+++ libcpp/configure.ac (working copy)
@@ -200,7 +200,7 @@ case $target in
tilegx*-*-* | tilepro*-*-* )
- need_64bit_hwint=no ;;
+ need_64bit_hwint=yes ;;
case $need_64bit_hwint:$ac_cv_sizeof_long in
--- gcc/config.gcc (revision 209890)
+++ gcc/config.gcc (working copy)
@@ -233,7 +233,7 @@ gnu_ld="$gnu_ld_flag"