On Wed, Dec 3, 2014 at 11:34 PM, DJ Delorie <d...@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.