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.
jeff
