> Sure, it would be nice if these things were pointers. At the moment, they are.
> However, I will reject any patch to support these alternative > pointers in C++ until all the language issues have been resolved. At the moment, there are no language issues to resolve. The only thing people were arguing about was the semantics of casting, and I agreed to using a builtin (because a plain cast won't work anyway). Everything else, except dereferencing and "implied pointers" (i.e. passing a reference, the '&' operator, etc), works just fine without any patches, so there's nothing to reject. It would be nice if dereferencing an odd pointer worked. It would definitely require target work, and probably MI work as well. I'm assuming that "dereferencing a pointer" is well defined regardless of the size of the pointer, at least at the language level. > Since you seem to be hesitant (and, reasonably so, in my opinion!) > to work on the language-design issues for C++, The remaining problems aren't really "language issues". The major problems are in the middle-end code, like optimizers, which blindly create pointers of size POINTER_SIZE when they take the address of things. The only language issue, other than C++'s "all pointers are the same size" rule, is that the target needs to participate a little more when one takes the address of something. It already participates a little, to provide alignment information. A full implementation - which I'm not asking for at this time - would need a hook to let the target generate the "address of objects" rather than have gcc blindly create a Pmode address. For example, if you declare a variable with "far" attribute, the backend doesn't get the chance to make the SYMBOL_REF :SI (for m32c) or :DI (for tpf), and if you hack that in anyway, other parts of gcc ignore it and change it to :Pmode.
