public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jeff Law <law@redhat.com>
Cc: gcc@gcc.gnu.org, dave.anglin@bell.net, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][RFC] Always require a 64bit HWI
Date: Wed, 30 Apr 2014 08:18:00 -0000	[thread overview]
Message-ID: <alpine.LSU.2.11.1404301011020.18709@zhemvz.fhfr.qr> (raw)
In-Reply-To: <5360029F.5020207@redhat.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  <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='@'

       reply	other threads:[~2014-04-30  8:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LSU.2.11.1404291307480.18709@zhemvz.fhfr.qr>
     [not found] ` <5360029F.5020207@redhat.com>
2014-04-30  8:18   ` Richard Biener [this message]
2014-04-30 16:47     ` Jeff Law
2014-04-30 16:59       ` John David Anglin
2014-05-01 15:14       ` Pedro Alves
2014-04-30 23:22     ` John David Anglin
2014-05-07 10:26     ` Richard Biener

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=alpine.LSU.2.11.1404301011020.18709@zhemvz.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=dave.anglin@bell.net \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gcc@gcc.gnu.org \
    --cc=law@redhat.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).