> I'm very suspicious of allowing users to specify this via attributes.
Me too, but that's what extensions are all about. You never know what the user is going to need to do. The M16C is an example - it has a 16 bit pointer, but has a few special opcodes for using a 32 bit pointer to access additional ROM data. Plus, functions exist in a 24 bit address space. > Having pointers-to-objects or pointers-to-functions with different sizes > (within one of those classes) seems problematic, but perhaps you can say > more about how you expect this to work in the presence of conversions > and such. I don't know about conversions, but I can easily imagine cases where the program's address space isn't as big as the chip's address space. Consider a 32-bit program on a 64-bit CPU, which needs to access memory mapped devices. Or an API converter that lets 32 bit programs run in a 64 bit OS. They'd need to compute pointers as integers of the right size, then cast them. > I expected that what you were asking was whether the back end could > reasonably say that function pointers had size four, say, while data > pointers had size two. I think that's reasonable, That is totally unsupported by GCC. I've ranted about that before, because the m16c has a 16 bit data pointer and a 24 bit function pointer. > but I don't find it nearly so reasonable to say that some "int *" > pointers have size four while others have size two. But, maybe I > just need appropriate motivation. Well, it seems to work just fine in C. Example: In m16c, you can declare an SImode pointer type, which is initialized to point to a function. The assembler does the right thing, letting you initialize a reset vector (32 bit pointers) without having to set up the RAM thunks to support 16 bit function pointers. > Also, there is a nasty class of bugs in G++ stemming from the GCC > attribute extensions because there are no well-defined rules about how > to tell if two types with different attributes are the same or > different, and if they are different what conversions (if any) can be > used to convert back and forth. We have target hooks for function attributes, no reason to avoid target hooks for data attributes.
