This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC][wide-int] Fix some build errors on arm in wide-int branch and report ICE


On 04/23/2014 10:36 AM, Richard Biener wrote:
On Wed, Apr 23, 2014 at 4:29 PM, Kenneth Zadeck
<zadeck@naturalbridge.com> wrote:
On 04/23/2014 05:47 AM, Richard Biener wrote:
On Tue, Apr 22, 2014 at 6:04 PM, Mike Stump <mikestump@comcast.net> wrote:
On Apr 22, 2014, at 8:33 AM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
Kyrill Tkachov <kyrylo.tkachov@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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]