pointer math vs named address spaces

[Richard Biener]

On Wed, Dec 3, 2014 at 11:34 PM, DJ Delorie <dj@redhat.com> wrote:
>
> If a target (rl78-elf in my case) has a named address space larger
> than the generic address space (__far in my case), why is pointer math
> in that named address space still truncated to sizetype?
>
> N1275 recognizes that named address spaces might be a different size
> than the generic address space, but I didn't see anything that
> required such truncation.
>
>
> volatile char __far * ptr1;
> volatile char __far * ptr2;
> uint32_t sival;
>
> foo()
> {
>   ptr2 = ptr1 + sival;
> }
>
> foo ()
> {
>   volatile <address-space-2> char * ptr2.5;
>   sizetype D.2252;
>   long unsigned int sival.4;
>   volatile <address-space-2> char * ptr1.3;
>   sizetype _3;
>
> ;;   basic block 2, loop depth 0
> ;;    pred:       ENTRY
>   ptr1.3_1 = ptr1;
>   sival.4_2 = sival;
>   _3 = (sizetype) sival.4_2;    <------- why this truncation?
>   ptr2.5_4 = ptr1.3_1 + _3;
>   ptr2 = ptr2.5_4;
>   return;
> ;;    succ:       EXIT
>
> }

Apart from what Joseph already said using 'sizetype' in the middle-end
for sizes and offsets is really really deep-rooted into the compiler.
What you see above is one aspect - POINTER_PLUS_EXPR offsets
are forced to have sizetype type.  But you'd also see it in the inability
to create larger than sizetype objects (DECL_SIZE_UNITs type).

So for the middle-end part I'd suggest you make sure that sizetype
covers the largest pointer-mode precision your target offers.  That of course
doesn't fix what Joseph pointed out - that the user will still run into issues
when writing C programs or when using the C runtime (I suppose TR 18037
doesn't specify alternate memcpy for different address spaces?)

Richard.