On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump <mikest...@comcast.net> wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford <rdsandif...@googlemail.com>
wrote:
Kyrill Tkachov <kyrylo.tkac...@arm.com> writes:
Ping.
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00769.html
Any ideas? I recall chatter on IRC that we want to merge wide-int into trunk
soon. Bootstrap failure on arm would prevent that...
Sorry for the late reply. I hadn't forgotten, but I wanted to wait
until I had chance to look into the ICE before replying, which I haven't
had chance to do yet.
They are separable issues, so, I checked in the change.
It's a shame we can't use C++ style casts,
but I suppose that's the price to pay for being able to write
"unsigned HOST_WIDE_INT”.
unsigned_HOST_WIDE_INT isn’t horrible, but, yeah, my fingers were expecting a
typedef or better. I slightly prefer the int (1) style, but I think we should
go the direction of the patch.
Well, on my list of things to try for 4.10 is to kill off HOST_WIDE_* and
require a 64bit integer type on the host and force all targets to use
a 64bit 'hwi'. Thus, s/HOST_WIDE_INT/int64_t/ (and the appropriate
related changes).
Richard.
I should point out that there is a community that wants to go in the
opposite direction here. They are the people with real 32 bit hosts
who want to go back to a world where they are allowed to make hwi a 32
bit value. They have been waiting wide-int to be committed because
they see this as a way to get back to world where most of the math is
done natively.
I am not part of this community but they feel that if the math that has
the potential to be big to be is done in wide-ints, then they can go
back to using a 32 bit hwi for everything else. For them, a wide-int
built on 32 hwi's would be a win.
kenny
