This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch: stab info for const fields
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Thu, 31 Oct 2002 14:25:40 -0800
- Subject: Re: Patch: stab info for const fields
--On Thursday, October 31, 2002 05:06:41 PM +0000 Richard Kenner
<kenner@vlsi1.ultra.nyu.edu> wrote:
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?
The C standard indicates that qualifiers do not matter in rvalue
contexts.
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.
Sure -- and they can use that fact even if B is not of type "const int".
If I write:
int b = 3;
and never modify or take the address of "b", the front end can set
TREE_READONLY on b.
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.
Again, this goes to Zack's point; we can allow two types to be compatible,
even if they are not the same. (That idea already exists in C/C++)
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com