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

> On Fri, Mar 16, 2012 at 12:33 PM, Tristan Gingold <ging...@adacore.com> wrote:
>> On Mar 16, 2012, at 12:02 PM, Richard Guenther wrote:
>>> On Fri, Mar 16, 2012 at 11:39 AM, Tristan Gingold <ging...@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.
> Ok.
>>>> 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 ?
> Well, this setup is not well supported by the middle-end (and indeed m32c
> has existing issues with that).  So in your case decoupling sizetype from
> size_t sounds like the more appropriate solution.
>>> 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.
> I'd choose SIZETYPE (for confusion, heh), defaulting to SIZE_TYPE.

Ok, thank you for your comments.


Reply via email to