Re: Patch: stab info for const fields

[Zack Weinberg <zack at codesourcery dot com>]

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