Re: does gcc support multiple sizes, or not?

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:
>> 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.

Sorry, but I think that's far too casual.  The long history of GCC
extensions causing various kinds of problems is proof positive that new
extensions should be added only with extreme care.  We've already
established the position that new extensions should come with a  list of
changes to the relevant language standards with the same rigor that
would be used to modify the language itself.

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

Well, I think it's in direct conflict with the C++ standard.  If "X" is
a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit
pointer type, then:

  (X*)(Y*)x

is supposed to get you back the value of "x", but I don't see how that
can work, in general.

So, if you want to do this in C++, you need to work through the language
standard and work out how having two distinct classes of pointers is
going to work.  I think that's doable, but not trivial.

For example, you might make the 16-bit pointers "pointers" what the
standard calls pointers, and then make the 32-bit pointers "big
pointers".  You could say that within a single class of pointers, all
the usual pointer rules apply.  Then, work through things like
conversions between the two (is one direction implicit?  are these
static_casts or reinterpret_casts?), what mangling to use for big
pointers, how to encode the types in RTTI, etc.

If you really just need these things in a few places (like reset
vectors), then I think you'd be better off with a
__builtin_long_pointer() intrinsic (returning a 32-bit integer, not
pointer) to use in the initializers.  You only need two classes of
pointers if you expect people to use the second class in non-trivial
expressions, i.e., dereference them, perform pointer arithmetic on them,
etc.

There's also nothing inherently wrong with assembly code; if it's
necessary to express the reset vector in assembly code, well, then, so
be it.  I can well see why doing it in C/C++ is nicer, but I don't think
we should try to extend GNU C/C++ to encompass everything that can be
done with an assembler.

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

Sure -- but you still have to say what the semantics are!  In my
opinion, "it seems to work" arguments are far too loose for making
semantic changes to the C++ front end.   We've been burned too many times.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713