This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] [PATCH] 32-bit pointers in x86-64
- From: "Jan Beulich" <jbeulich at novell dot com>
- To: "Luca" <luca dot b633 at gmail dot com>,"Andrew Pinski" <pinskia at gmail dot com>
- Cc: <gcc at gcc dot gnu dot org>,<binutils at sourceware dot org>, <linux-kernel at vger dot kernel dot org>
- Date: Wed, 05 Dec 2007 09:31:20 +0000
- Subject: Re: [RFC] [PATCH] 32-bit pointers in x86-64
- References: <1ba5638c0711250829o416e3ccasba572d3c205ea7f4@mail.gmail.com> <de8d50360711251045l4566f894m92fbb32d00fa362@mail.gmail.com>
>>> "Andrew Pinski" <pinskia@gmail.com> 25.11.07 19:45 >>>
>On 11/25/07, Luca <luca.b633@gmail.com> wrote:
>> 7.1. Add __attribute__((pointer_size(XXX))) and #pragma pointer_size
>> to allow 64-bit pointers in 32-bit mode and viceversa
>
>This is already there, try using __attribute__((mode(DI) )).
Hmm, unless this is a new feature in 4.3, I can't seem to get this to work on
either i386 (using mode DI) or x86-64 (using mode SI). Could you clarify? If
this worked consistently on at least all 64-bit architectures, I would have a
use for it in the kernel (cutting down the kernel size by perhaps several
pages). Btw., I continue to think that the error message 'initializer element
is not computable at load time' on 64-bit code like this
extern char array[];
unsigned int p = (unsigned long)array;
or 32-bit code like this
extern char array[];
unsigned long long p = (unsigned long)array;
is incorrect - the compiler generally has no knowledge what 'array' is (it may
know whether the architecture is generally capable of expressing the
necessary relocation, but if 'array' is really a placeholder for an assembly
level constant, possibly even defined through __asm__() in the same
translation unit, this diagnostic should at best be a warning). I'm pretty
sure I have an open bug for this, but the sad thing is that bugs like this
never appear to really get looked at.
Thanks, Jan