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. Tristan.
