This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: pointer math vs named address spaces
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 4 Dec 2014 10:54:05 +0100
- Subject: Re: pointer math vs named address spaces
- Authentication-results: sourceware.org; auth=none
- References: <201412032234 dot sB3MYEmp030041 at greed dot delorie dot com>
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.