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 <rguent...@suse.de>
> >
> > 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?).
Thanks,
Richard.
2014-04-29 Richard Biener <rguent...@suse.de>
libcpp/
* configure.ac: Always set need_64bit_hwint to yes.
* configure: Regenerated.
* config.gcc: Always set need_64bit_hwint to yes.
Index: libcpp/configure.ac
===================================================================
--- libcpp/configure.ac (revision 209890)
+++ libcpp/configure.ac (working copy)
@@ -200,7 +200,7 @@ case $target in
tilegx*-*-* | tilepro*-*-* )
need_64bit_hwint=yes ;;
*)
- need_64bit_hwint=no ;;
+ need_64bit_hwint=yes ;;
esac
case $need_64bit_hwint:$ac_cv_sizeof_long in
Index: gcc/config.gcc
===================================================================
--- gcc/config.gcc (revision 209890)
+++ gcc/config.gcc (working copy)
@@ -233,7 +233,7 @@ gnu_ld="$gnu_ld_flag"
default_use_cxa_atexit=no
default_gnu_indirect_function=no
target_gtfiles=
-need_64bit_hwint=
+need_64bit_hwint=yes
need_64bit_isa=
native_system_header_dir=/usr/include
target_type_format_char='@'
