> This means that the largest int on the host must be at least half the
> size of the largest int on the target. Hence, building 64-bit target
> compilers on 32-bit host systems has never been a problem.
I'm not sure I'd go as far as saying "has never been a problem". It's
"mostly worked", b
Jim Wilson wrote:
This does mean that you can't build a 128-bit target compiler on a
32-bit host, but that hasn't been a problem yet.
And now that we allow HOST_WIDE_INT to be defined as long long, this
shouldn't be a problem any more either. A 32-bit host with 2 long longs
gets us up to 1
Michael Eager wrote:
Is it guaranteed to hold all target integer sizes? How
does this work for 32-bit hosts and 64-bit targets?
RTL and tree constants were defined from the beginning as two
HOST_WIDE_INTs. This was necessary to bootstrap long long support on
32-bit systems before most compi
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote:
Eric Botcazou wrote:
>> How does this work for 32-bit hosts and 64-bit targets?
>
> Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
No, he said they require a 64 bit HOST_WIDE
On 7/12/07, Michael Eager <[EMAIL PROTECTED]> wrote:
Meaning that I can't build gcc-ppc64 on an IA32 host?
HUH? Yes you can, HWI is a64bit integer type there (aka long long).
-- Pinski
Eric Botcazou wrote:
How does this work for 32-bit hosts and 64-bit targets?
Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
Meaning that I can't build gcc-ppc64 on an IA32 host?
Yuck! So much for cross-platform tools.
--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo
> Sorry: I guess my information is dated. What changed so that it's now
> required?
I presume the reasons you gave + the usual nasty bugs prompted someone to
decide that it was not worth the troubles after all.
--
Eric Botcazou
> > They don't REQUIRE it, but just miss a lot of optimization if that isn't
> > the case (since things that would otherwise be CONST_INT will now be
> > CONST_DOUBLE and folding will be harder).
>
> # need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide
> # for
> They don't REQUIRE it, but just miss a lot of optimization if that isn't
> the case (since things that would otherwise be CONST_INT will now be
> CONST_DOUBLE and folding will be harder).
# need_64bit_hwint Set to yes if HOST_WIDE_INT must be 64 bits wide
# for this ta
> > How does this work for 32-bit hosts and 64-bit targets?
>
> Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
They don't REQUIRE it, but just miss a lot of optimization if that isn't
the case (since things that would otherwise be CONST_INT will now be
CONST_DOUBLE and folding will b
> How does this work for 32-bit hosts and 64-bit targets?
Some (most?) 64-bit targets require a 64-bit HOST_WIDE_INT.
--
Eric Botcazou
> HOST_WIDE_INT is the wide integer type used throughout the compiler.
I haven't looked at the definition.
Is it guaranteed to hold all target integer sizes?
No.
How does this work for 32-bit hosts and 64-bit targets?
Often we use "long long" for HOST_WIDE_INT, but in other c
Eric Botcazou wrote:
Why would the RTL represent target CONST_INT as HOST_WIDE_INT?
HOST_WIDE_INT is the wide integer type used throughout the compiler.
I haven't looked at the definition.
Is it guaranteed to hold all target integer sizes? How
does this work for 32-bit hosts and 64-bit targ
> Why would the RTL represent target CONST_INT as HOST_WIDE_INT?
HOST_WIDE_INT is the wide integer type used throughout the compiler.
--
Eric Botcazou
Mike Stump wrote:
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files. This
means
Ian Lance Taylor wrote:
Michael Eager <[EMAIL PROTECTED]> writes:
It seems to me that the same assembly code should be generated
independent of whether gcc is run on a 32-bit or 64-bit
host and all of these HOST_* tests should actually be
target domain parameters, like BITS_PER_WORD.
It is sa
On Jul 12, 2007, at 9:23 AM, Michael Eager wrote:
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
When QAing, it is very useful to be able to compare two .s files.
This means that we should st
Michael Eager <[EMAIL PROTECTED]> writes:
> I was looking through dwarf2out.c, tracking down the
> cause for different assembly code being generated
> when gcc was run on 32-bit and 64-bit hosts.
>
> In dwarf2out.c, there are several places where decisions
> about what to generate in the .s file
On 12 July 2007 17:51, Andrew Pinski wrote:
> On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
>> On 12 July 2007 17:23, Michael Eager wrote:
>>
>> Sounds right to me. Basing codegen decisions on HOST_ is just plain
>> wrong and has been an ongoing source of bugs down the years.
>
> Exce
On 7/12/07, Dave Korn <[EMAIL PROTECTED]> wrote:
On 12 July 2007 17:23, Michael Eager wrote:
Sounds right to me. Basing codegen decisions on HOST_ is just plain
wrong and has been an ongoing source of bugs down the years.
Except in this case, the code gen is the same, just the assembly
On 12 July 2007 17:23, Michael Eager wrote:
> I was looking through dwarf2out.c, tracking down the
> cause for different assembly code being generated
> when gcc was run on 32-bit and 64-bit hosts.
>
> In dwarf2out.c, there are several places where decisions
> about what to generate in the .s fil
I was looking through dwarf2out.c, tracking down the
cause for different assembly code being generated
when gcc was run on 32-bit and 64-bit hosts.
In dwarf2out.c, there are several places where decisions
about what to generate in the .s file are based on
HOST_BITS_PER_WIDE_INT or HOST_BITS_PER_W
22 matches
Mail list logo
