This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: stab info for const fields


Zack Weinberg <zack@codesourcery.com> writes:

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

Maybe what you had in mind has no language dependency, but that is not
transparent from the description you gave and at two persons don't see
the non-dependency.  If your definition is language independent and
precise then there ought to be possible to express it so that we can
check that the implementation matches what you intended and also our
understanding. 

|  Let me go over it again hopefully described better:
| 
|  - We get rid of the ambiguously defined NOP_EXPR and CONVERT_EXPR.

This part I do understand.

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

I see that your examples try to make more precise the preceeding
assertion. IMO, we ought to define precisely the exceptional cases so
that every can check that the description is really language
indepeendent.

[...]

| Does it make more sense now? 

For me, that sheds more light on what you said earlier.  Still, I'm
uncomfortable with the non-exceptional cases not being precisely
defined.  If that part is resolved, I would see no reason not to go
with what you're proposing.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]