This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH][RFC][wide-int] Fix some build errors on arm in wide-int branch and report ICE
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Richard Sandiford <rdsandiford at googlemail dot com>, Kyrill Tkachov <kyrylo dot tkachov at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 23 Apr 2014 10:48:28 -0400
- Subject: Re: [PATCH][RFC][wide-int] Fix some build errors on arm in wide-int branch and report ICE
- Authentication-results: sourceware.org; auth=none
- References: <534D11EB dot 9020806 at arm dot com> <53568069 dot 7010503 at arm dot com> <87mwfdtm3y dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm dot com> <496FABF5-26F4-42B1-B6C6-267CDD2BE6A3 at comcast dot net> <CAFiYyc1sDHVXKp60JFMMAGjFxOaneVJOqLTDgLt4_0Y5gw1R7g at mail dot gmail dot com> <5357CE44 dot 40000 at naturalbridge dot com> <CAFiYyc0YCnTMp-R8bccPyj0G=pPecUTzRbL917Mwt6-NtUPbVw at mail dot gmail dot com>
On 04/23/2014 10:36 AM, Richard Biener wrote:
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.
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump <email@example.com> wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
Kyrill Tkachov <firstname.lastname@example.org> writes:
Any ideas? I recall chatter on IRC that we want to merge wide-int into
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 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
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.
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.