Patch: stab info for const fields
Zack Weinberg
zack@codesourcery.com
Thu Oct 31 20:17:00 GMT 2002
On Fri, Nov 01, 2002 at 01:21:17AM +0100, Gabriel Dos Reis wrote:
> kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:
>
> | If you look again at the bit you snipped, the implementation I
> | suggested should be totally language-independent (in the
> | language-independent parts of the compiler).
> |
> | Yes, the *implementation* is, but the *definition* is not, so that when
> | people are looking at a tree, they can't know whether it's valid or not
> | without knowlege of the language in question and I think that's a bad idea.
>
> I strongly agree with Kenner on this point. There ought to be a
> precise definition. I support option (1) and won't oppose to (2).
> But (3) or (3a) aren't workable, IMO.
I really don't understand the objections here. The definition I had
in mind had no language dependencies either in the definition or the
implementation. Let me go over it again hopefully described better:
- We get rid of the ambiguously defined NOP_EXPR and CONVERT_EXPR.
- In the language-independent tree representation, whenever a tree
with type A has an operand with type B, A not identical to B, the
operand is implicitly converted to type A before the operation
occurs. Most of the time there is just one, well-defined,
conversion operation that makes sense in any such context. If
there is none, or if there could be multiple intended semantics,
the tree is ill-formed; the middle-end will abort if handed such a
tree. (Examples: coercion between float and integer has several
possible semantics, and it's ambiguous which one is meant; coercion
between aggregate types is ill-defined.)
- For situations where there is a choice of multiple intended
conversion semantics, we define special unary conversion operators
to make the choice explicit. For instance, for floating point
conversion, the existing FIX_*_EXPR and FLOAT_EXPR will do nicely.
We will also want a REINTERPRET_EXPR that means "reinterpret the
bits of this expression according to a different type". It is the
language's responsibility to insert these operators into trees
wherever necessary.
- Each language front end is responsible for checking all constraints
imposed by its type algebra. The language-independent trees have
no such constraints; whatever is possible is permitted.
Does it make more sense now? If you still disagree with me that this
semantic is well-defined and language-independent, please give an
example of a tree that you think would be ambiguous.
zw
More information about the Gcc-patches
mailing list