* Re: [PATCH][RFC] Always require a 64bit HWI
[not found] ` <5360029F.5020207@redhat.com>
@ 2014-04-30 8:18 ` Richard Biener
2014-04-30 16:47 ` Jeff Law
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Richard Biener @ 2014-04-30 8:18 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc, dave.anglin, gcc-patches
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='@'
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] Always require a 64bit HWI
2014-04-30 8:18 ` [PATCH][RFC] Always require a 64bit HWI Richard Biener
@ 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
2 siblings, 2 replies; 6+ messages in thread
From: Jeff Law @ 2014-04-30 16:47 UTC (permalink / raw)
To: Richard Biener; +Cc: gcc, dave.anglin, gcc-patches
On 04/30/14 02:16, Richard Biener wrote:
> 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?).
My recollection is that HP aCC supports long long, but I don't recall
when support for that was introduced. I'm really trying hard to forget
hpux-isms.
Plus, they can always start the bootstrapping process with GCC 4.9.
jeff
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] Always require a 64bit HWI
2014-04-30 16:47 ` Jeff Law
@ 2014-04-30 16:59 ` John David Anglin
2014-05-01 15:14 ` Pedro Alves
1 sibling, 0 replies; 6+ messages in thread
From: John David Anglin @ 2014-04-30 16:59 UTC (permalink / raw)
To: Jeff Law, Richard Biener; +Cc: gcc, gcc-patches
On 4/30/2014 12:00 PM, Jeff Law wrote:
> My recollection is that HP aCC supports long long, but I don't recall
> when support for that was introduced. I'm really trying hard to
> forget hpux-isms.
>
> Plus, they can always start the bootstrapping process with GCC 4.9.
I can't remember but without ansi support one needs to start with
an early 4.X version.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] Always require a 64bit HWI
2014-04-30 8:18 ` [PATCH][RFC] Always require a 64bit HWI Richard Biener
2014-04-30 16:47 ` Jeff Law
@ 2014-04-30 23:22 ` John David Anglin
2014-05-07 10:26 ` Richard Biener
2 siblings, 0 replies; 6+ messages in thread
From: John David Anglin @ 2014-04-30 23:22 UTC (permalink / raw)
To: Richard Biener; +Cc: Jeff Law, gcc, gcc-patches
On 30-Apr-14, at 4:16 AM, Richard Biener wrote:
> 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?).
I'm OK with this change as I know this causes support issues. The HP
ansi
C compiler and aCC have long long. This is not an issue for linux. I
believe
people can find HP-UX GCC binaries on the net.
Dave
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] Always require a 64bit HWI
2014-04-30 16:47 ` Jeff Law
2014-04-30 16:59 ` John David Anglin
@ 2014-05-01 15:14 ` Pedro Alves
1 sibling, 0 replies; 6+ messages in thread
From: Pedro Alves @ 2014-05-01 15:14 UTC (permalink / raw)
To: Jeff Law; +Cc: Richard Biener, gcc, dave.anglin, gcc-patches
On 04/30/2014 05:00 PM, Jeff Law wrote:
> On 04/30/14 02:16, Richard Biener wrote:
>>
>> 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?).
> My recollection is that HP aCC supports long long, but I don't recall
> when support for that was introduced. I'm really trying hard to forget
> hpux-isms.
GCC (in libdecnumber) has been relying on long long / ll existing, and on
it being 64-bits wide, for more than 7 years now, and nobody seems to have
tripped on any host compiler that doesn't support it.
See libdecnumber/bid/bid-dpd.h / bid/bid2dpd_dpd2bid.h. git blame shows:
10de71e1 (meissner 2007-03-24 17:04:47 +0000 25) typedef unsigned int UINT32;
^^^^^^^^^^
10de71e1 (meissner 2007-03-24 17:04:47 +0000 26) typedef unsigned long long UINT64;
^^^^^^^^^
10de71e1 (meissner 2007-03-24 17:04:47 +0000 27) typedef struct { UINT64 w[2]; } UINT128;
...
10de71e1 (meissner 2007-03-24 17:04:47 +0000 28) { { 0x3b645a1cac083127ull, 0x0083126e978d4fdfull } }, /* 3 extra digits */
10de71e1 (meissner 2007-03-24 17:04:47 +0000 29) { { 0x4af4f0d844d013aaULL, 0x00346dc5d6388659ULL } }, /* 10^(-4) * 2^131 */
^^^
So the issue is moot.
> Plus, they can always start the bootstrapping process with GCC 4.9.
They'd have to go much further back than that.
--
Pedro Alves
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH][RFC] Always require a 64bit HWI
2014-04-30 8:18 ` [PATCH][RFC] Always require a 64bit HWI Richard Biener
2014-04-30 16:47 ` Jeff Law
2014-04-30 23:22 ` John David Anglin
@ 2014-05-07 10:26 ` Richard Biener
2 siblings, 0 replies; 6+ messages in thread
From: Richard Biener @ 2014-05-07 10:26 UTC (permalink / raw)
To: Jeff Law; +Cc: gcc, dave.anglin, gcc-patches
On Wed, 30 Apr 2014, Richard Biener wrote:
> 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?).
I have now applied the patch (as it is said to fix wide-int merge
fallout). The plan is to go forward with cleanups that are
possible after this throughout stage1 (I sent the first cleanup
patch already, but further ones should wait until we released
4.9.1 to not make backports harder than necessary).
Richard.
> 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='@'
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-05-07 10:26 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <alpine.LSU.2.11.1404291307480.18709@zhemvz.fhfr.qr>
[not found] ` <5360029F.5020207@redhat.com>
2014-04-30 8:18 ` [PATCH][RFC] Always require a 64bit HWI Richard Biener
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
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).