This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Always require a 64bit HWI


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  <rguenther@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  <rguenther@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='@'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]