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='@'
next parent 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).