This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch]: Uncouple size_t and sizetype


On Mar 16, 2012, at 12:02 PM, Richard Guenther wrote:

> On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold <gingold@adacore.com> wrote:
>> Hi,
>> 
>> currently sizetype precision (cf store-layout.c:initialize_sizetypes) is the same as size_t.
>> This is an issue on VMS, where size_t is 'unsigned int', but we'd like to have a 64 bit sizetype
>> for Ada.  My understanding is that ISO-C doesn't require size_t precision to match the one of
>> void *.
>> 
>> We can't really lie about size_t because it is exposed in API (such as writev).
>> 
>> I don't see any reason (other than historic one) to have an exact match between sizetype and size_t.
>> So this patch adds an hook to allow targets to define sizetype.
> 
> Well, there is at least "common sense" that couples size_t and sizetype.
> As you can at most allocate size_t memory via malloc (due to its size_t
> use for the size) sizes larger than what fits into size_t do not make much
> sense.  Thus, a sizetype larger than size_t does not make much sense.

Agreed, but malloc() is not the only way to get memory.  At least on VMS, there are
some syscalls to allocate memory with a 64 bit length argument.

> The middle-end of course would not care much what you use for sizetype.
> But be warned - if the mode for sizetype is different of ptr_mode things
> are going to be interesting for you (yes, ptr_mode, not Pmode).

That's the issue.  POINTER_SIZE is 64 bits (when -mpointer-size=64) but size_t should always be 32 bit.

>> I initially thought about using Pmode precision for sizetype precision, but there are a few machines
>> (m32c, sh, h8300) where the precisions aren't the same.  I don't know wether this is on purpose or
>> unintentional.
> 
> At least for m32c it is IIRC because 24bit computations are soo expensive
> on that target, so HImode is chosen for sizetype.

That's a good reason!

> So - why do you need a 64bit sizetype again? ;)
> 
> Can it be that you don't really need 64bit sizes but you hit issues with
> sizetype != ptr_mode size?

I don't have an urgent need for 64bit sizes (although would be nice to have them).

I remember that the first build with sizetype=32 but ptr_mode =DImode was a failure.
Maybe I should first investigate this path, as m32c could use "unsigned int" (16 bits)
for size_type alongside 32 for POINTER_SIZE ?

> Btw, while we are transitioning to target hooks in this case I'd prefer
> a target macro alongside the existing SIZE_TYPE, etc. ones.

Ok.

Tristan.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]