Quoting "H.J. Lu" :
What is the run-time result when overflow happens?
Assuming you use a 32 bit unsigned base address, and the space beyond 4G
is unmapped, you'll get a SEGV.
On Sun, May 13, 2012 at 8:16 PM, Joern Rennecke wrote:
> Quoting "H.J. Lu" :
>
>> On Sun, May 13, 2012 at 6:17 PM, wrote:
>>>
>>> Quoting "H.J. Lu" :
>>>
What is the expect run-time behavior when a + b has
overflow/underflow?
>>>
>>>
>>>
>>> The expectation is wrap-around. Note that l
Quoting "H.J. Lu" :
On Sun, May 13, 2012 at 6:17 PM, wrote:
Quoting "H.J. Lu" :
What is the expect run-time behavior when a + b has
overflow/underflow?
The expectation is wrap-around. Note that loop strenght reduction can
cause assumed wrap-around semantics in RTL for strictly conformin
On May 13, 2012, at 21:17, amyl...@spamcop.net wrote:
> The expectation is wrap-around. Note that loop strenght reduction can
> cause assumed wrap-around semantics in RTL for strictly conforming C input
> where no such wrap-around is in evidence.
Really, we should define signed integer arithmeti
On Sun, May 13, 2012 at 6:17 PM, wrote:
> Quoting "H.J. Lu" :
>
>> What is the expect run-time behavior when a + b has
>> overflow/underflow?
>
>
> The expectation is wrap-around. Note that loop strenght reduction can
> cause assumed wrap-around semantics in RTL for strictly conforming C input
>
Quoting "H.J. Lu" :
What is the expect run-time behavior when a + b has
overflow/underflow?
The expectation is wrap-around. Note that loop strenght reduction can
cause assumed wrap-around semantics in RTL for strictly conforming C input
where no such wrap-around is in evidence.
Quoting "H.J. Lu" :
Will x86 backend ever see a memory address with wrap around.
Actually, just this kind of problem made the indexed addressing mode
for SH64 for the ABIs with 32 bit addresses unusable.
If your MMU supports it, you can try to map the second 4 GB * maximum scale
mapped to the
Snapshot gcc-4.8-20120513 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120513/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Sun, May 13, 2012 at 12:01 PM, Richard Guenther
wrote:
> On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
>> Hi,
>>
>> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
>> 64-bit address is base + index * scale + offset:
>> 1. Base is 64bit.
>> 2. Index is 64bit.
>> 3. O
On Sun, May 13, 2012 at 6:32 PM, H.J. Lu wrote:
> Hi,
>
> I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
> 64-bit address is base + index * scale + offset:
> 1. Base is 64bit.
> 2. Index is 64bit.
> 3. Offset is 8bit or 32bit
>
> 0x67 address size prefix is used to zero-
Hi all,
I have started work on a new gcc back-end for the DCPU-16 architecture.
DCPU-16 is a virtual processor that is supposed to be an in-game feature
of the upcoming game 0x10c (see http://0x10c.com)
The project is hosted at https://github.com/frot/gcc-dcpu16.
Nothing to see there yet. I ha
Hi,
I am trying to optimize memory address for x32. X32 runs in 64-bit mode.
64-bit address is base + index * scale + offset:
1. Base is 64bit.
2. Index is 64bit.
3. Offset is 8bit or 32bit
0x67 address size prefix is used to zero-extend 32bit address to 64bit:
1. Upper 32bits of base or index c
12 matches
Mail list logo
