Bug 16115, C++ invisible references

Jason Merrill jason@redhat.com
Wed Jul 7 17:53:00 GMT 2004


On Tue, 06 Jul 2004 15:33:05 -0700, Mark Mitchell <mark@codesourcery.com> wrote:

> EDG provides unlowered IL C++ that looks a lot like the source (but in a
> form that would be very easy for an interpreter to execute) and lowered IL
> (which looks like C, with magic for exceptions).  This model has been very
> successful; compiler vendors generally use the lowered form, while other
> tools vendors use the unlowered form.

Good to know.  In that form are destructor calls explicit, or are they
generated during lowering?

>>'for' scoping comes to mind; the scope of a declaration in the
>>for-init-statement is larger than its sub-tree, so to do anything
>>sensible with it we need to move it outside the loop construct.
>>
> Are you referring to the pre-ARM scoping rules?  Otherwise, I'm confused;
> a for-statement defines a scope, and there's nothing wrong with a
> representation that looks like:
>
>   (for init-statement test-expr increment-expr body)

The problem with that representation is that it requires something like
SCOPE_STMT to express scopes that can't clearly nest with other tree nodes.
This makes it hard to do anything that involves reasoning about scoping.
If you're going to lower this form before you try to do anything with it,
that isn't a big problem, but I would expect this to be a hassle for other
tools as well.

>>Your other suggestion gets back to the question above of conformity to the
>>source.  Is it worth the cost of building and throwing away all these extra
>>nodes just to have the parse trees match the C++ syntax more closely?

> I think so, yes.  I'm also not convinced it's that many nodes, or that we
> can't overwrite existing nodes rather than creating new ones.  But, I agree
> that there's a non-zero cost in doing a lowering phase.
>
> I think Gaby, at least, agrees with me.
>
> Rather than having early-lowering code creep in, I think we should reach
> some kind of conclusion, and then act accordingly, whatever conclusion we
> reach.

I agree that we need to resolve this design issue now.

Jason



More information about the Gcc-patches mailing list