Re: vtables patch 1/3: allow empty array initializations

2013-04-28 Thread DJ Delorie
For m32c chips, The address space is a flat 24-bit address space. Address registers are 24 bits (i.e. they cannot hold an SImode) but size_t is 16 bits originally because there aren't enough 24-bit math ops and 32-bit math is too expensive. I've tried to use PSImode for size_t recently (different

Re: vtables patch 1/3: allow empty array initializations

2013-04-28 Thread Bernd Schmidt
On 04/28/2013 11:13 PM, DJ Delorie wrote: > >> I have patches to let one specify a precision for partial int types, >> easy enough to do, and the rest of the compiler plays nicely for the >> most part with it... > > If you can make size_t truly be a 24-bit value, I'd be very happy :-) This confu

Re: vtables patch 1/3: allow empty array initializations

2013-04-28 Thread DJ Delorie
> I have patches to let one specify a precision for partial int types, > easy enough to do, and the rest of the compiler plays nicely for the > most part with it... If you can make size_t truly be a 24-bit value, I'd be very happy :-)

Re: vtables patch 1/3: allow empty array initializations

2013-04-28 Thread Mike Stump
On Apr 26, 2013, at 4:05 AM, Bernd Schmidt wrote: > On 04/24/2013 09:14 PM, DJ Delorie wrote: >>> 24 bits stored as three bytes, or four? How does this affect vtable >>> layout? I would have expected the C++ frontend and libsupc++ to >>> currently be inconsistent with each other given such a setup

Re: vtables patch 1/3: allow empty array initializations

2013-04-26 Thread Bernd Schmidt
On 04/24/2013 09:14 PM, DJ Delorie wrote: >> 24 bits stored as three bytes, or four? How does this affect vtable >> layout? I would have expected the C++ frontend and libsupc++ to >> currently be inconsistent with each other given such a setup. > > In memory, four, I think. The address registers

Re: vtables patch 1/3: allow empty array initializations

2013-04-24 Thread DJ Delorie
> 24 bits stored as three bytes, or four? How does this affect vtable > layout? I would have expected the C++ frontend and libsupc++ to > currently be inconsistent with each other given such a setup. In memory, four, I think. The address registers really are three bytes though. They're PSImode

Re: vtables patch 1/3: allow empty array initializations

2013-04-24 Thread Bernd Schmidt
On 04/24/2013 05:10 PM, DJ Delorie wrote: > >> this isn't true, it would be helpful to know. Given the size_t/uintptr_t >> testsuite patch I just submitted I'm thinking they don't exist, but I'm >> kind of wondering about m32c, so Cc'ing DJ. > > For m32c-elf with -mcpu=m32c, size_t is 16 bits but

Re: vtables patch 1/3: allow empty array initializations

2013-04-24 Thread DJ Delorie
> this isn't true, it would be helpful to know. Given the size_t/uintptr_t > testsuite patch I just submitted I'm thinking they don't exist, but I'm > kind of wondering about m32c, so Cc'ing DJ. For m32c-elf with -mcpu=m32c, size_t is 16 bits but void* is 24 bits.

vtables patch 1/3: allow empty array initializations

2013-04-24 Thread Bernd Schmidt
This is a patch series that changes the way vtables are constructed in the C++ frontend (the first two are small preliminary patches, the meat will be in 3/3). The problem I was trying to solve was that on the port I was working on, function pointers are smaller than data pointers, and size_t is sm