public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Pointer arithmetic
@ 2013-07-09 16:37 Hendrik Greving
  2013-08-07 20:40 ` Oleg Endo
  0 siblings, 1 reply; 3+ messages in thread
From: Hendrik Greving @ 2013-07-09 16:37 UTC (permalink / raw)
  To: gcc

On a machine with ABI ILP32LL64:

(insn 123 122 124 (nil) (set (reg:SI 392)
        (mem:SI (plus:SI (reg/v:SI 386)
                (reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 (nil)
    (nil))

If we support legitimate memory addresses like [r1+r2] (e.g. indexed
addresses), can the above RTL match such a load? I am asking because
of overflows, I am not sure how that part is defined, and where the
Spec is. What do I need to check in the backend for such a definition?
Is this POINTER_SIZE? E.g. what if the machine supports > 32 bits, who
is responsible to make sure that there is no overflow > 32 bits in
this case? Compiler? Assembler? Or even the user?

Thanks,
Hendrik

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Pointer arithmetic
  2013-07-09 16:37 Pointer arithmetic Hendrik Greving
@ 2013-08-07 20:40 ` Oleg Endo
  2013-08-07 22:43   ` Hendrik Greving
  0 siblings, 1 reply; 3+ messages in thread
From: Oleg Endo @ 2013-08-07 20:40 UTC (permalink / raw)
  To: Hendrik Greving; +Cc: gcc

On Tue, 2013-07-09 at 09:37 -0700, Hendrik Greving wrote:
> On a machine with ABI ILP32LL64:
> 
> (insn 123 122 124 (nil) (set (reg:SI 392)
>         (mem:SI (plus:SI (reg/v:SI 386)
>                 (reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 (nil)
>     (nil))
> 
> If we support legitimate memory addresses like [r1+r2] (e.g. indexed
> addresses), can the above RTL match such a load? 

On 32 bit address machines it should match.

> I am asking because
> of overflows, I am not sure how that part is defined, and where the
> Spec is. What do I need to check in the backend for such a definition?
> Is this POINTER_SIZE? E.g. what if the machine supports > 32 bits, who
> is responsible to make sure that there is no overflow > 32 bits in
> this case? Compiler? Assembler? Or even the user?

AFAIK overflow is undefined and thus anything can happen.  Induction
variable and loop optimizations may produce interesting things if
addresses overflow.  For example, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190

Cheers,
Oleg

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Pointer arithmetic
  2013-08-07 20:40 ` Oleg Endo
@ 2013-08-07 22:43   ` Hendrik Greving
  0 siblings, 0 replies; 3+ messages in thread
From: Hendrik Greving @ 2013-08-07 22:43 UTC (permalink / raw)
  To: Oleg Endo; +Cc: gcc

Yes I guess otherwise you could never produce a complex address like
that. Actually I think I remember that day that I found that C
explicitly leaves it undefined and to the machine.
Thanks
Hendrik

On Wed, Aug 7, 2013 at 1:40 PM, Oleg Endo <oleg.endo@t-online.de> wrote:
> On Tue, 2013-07-09 at 09:37 -0700, Hendrik Greving wrote:
>> On a machine with ABI ILP32LL64:
>>
>> (insn 123 122 124 (nil) (set (reg:SI 392)
>>         (mem:SI (plus:SI (reg/v:SI 386)
>>                 (reg/v:SI 349)) [0 sec 0 space 0, cmsmode 0 S4 A32])) -1 (nil)
>>     (nil))
>>
>> If we support legitimate memory addresses like [r1+r2] (e.g. indexed
>> addresses), can the above RTL match such a load?
>
> On 32 bit address machines it should match.
>
>> I am asking because
>> of overflows, I am not sure how that part is defined, and where the
>> Spec is. What do I need to check in the backend for such a definition?
>> Is this POINTER_SIZE? E.g. what if the machine supports > 32 bits, who
>> is responsible to make sure that there is no overflow > 32 bits in
>> this case? Compiler? Assembler? Or even the user?
>
> AFAIK overflow is undefined and thus anything can happen.  Induction
> variable and loop optimizations may produce interesting things if
> addresses overflow.  For example, see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
>
> Cheers,
> Oleg
>

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-08-07 22:43 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-09 16:37 Pointer arithmetic Hendrik Greving
2013-08-07 20:40 ` Oleg Endo
2013-08-07 22:43   ` Hendrik Greving

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).