Re: Patch: stab info for const fields

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    GCC is pretty clear on the idea that the type system is, roughly
    speaking, the C type system.  The front end's job is to translate its
    own type system into that type system.

Right, but we haven't been as clear as we should be on what "the C type
system" is.  That's basically what started this: what about readonly?
Consider (going back to C):

	int a;
	const int b;

	... a + b ...

What does that PLUS_EXPR look like?  If A and B are different types (with
a different TREE_READONLY), then we have to have a conversion in that
PLUS_EXPR.  Sure the optimizer can "do the right thing" and ignore it,
but those conversions aren't making things any easier.

    If you have declarations whose size is not that of their type, you
    have to say more about what tree operations are legal in the middle
    end.  Can you use a MODIFY_EXPR to assign these out-sized objects to
    ordinary-sized objects?  Normally, the constraint on a MODIFY_EXPR is
    that the two operands have the same type.  This is but the tip of the
    iceberg.

Yes, but I think they can all be solved the way the PLUS_EXPR above is:
the *operation* is, semantically, that of its type.  However, the optimizers
are allowed to use the fact that B is constant.  Similarly with a MODIFY_EXPR
in the aggregate case: only the size corresponding to the type is modified,
but if one operand is actually more aligned that the type, the optimizer and
code generator is allowed to take advantage of that.