On 04/23/2014 10:36 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
<zad...@naturalbridge.com> wrote:
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.
That wide-int builds on HWI is an implementation detail. It can easily
be changed to build on int32_t.
Btw, what important target still supports a 32bit HWI? None for what
I know. Look at config.gcc and what does _not_ set need_64bit_hwint.
Even plain arm needs it.
I think that originally, hwi was supposed to be a natural integer on the
host machine and it was corrupted to always be a 64 bit integer.
Right now, wide-int is built on hwis which are always 64 bits. On a
32 bit machine, this means that there are two levels of abstraction to
get to the hardware, one to get from wide-int to 64 bits and one to get
from 64 bits to 32 bits.
The easy part of converting wide-int to run natively on a 32 bit machine
is going to be the internals of wide-int. Of course until you test it
you never know, but we did try very hard not to care about the internal
size of the rep. The hard part will be the large number of places
where wide-int converts to or from hwi. Some of those callers expect
things to really be 64 bits and some of them deal with numbers that are
always small enough to be implemented in the efficient native
representation. I think that the push against you is that the latter
case should not be converted to int64_t.
Richard.
kenny
