[PATCH] Fix type correctness of fold_indirect_ref

[Mark Mitchell]

Steven Bosscher wrote:

>>That's orthogonal.  There's no reason you can't write a great front end
>>using trees.
> 
> 
> But it is hard to write a great back end using trees when at least one
> front end has its own set of rules about using trees.

No, that's not true either.  It's hard to write a great back end when 
you try to interleave the front end and the back end.  If the front end 
works for a while, stops, and hands some well-defined data structures to 
the back end in the format the back end wants, there's no problem.

> G++ abuses trees in horrible ways by linking together trees of different
> kinds (e.g. TREE_LISTs, *_DECLs, and OVERLOADs) and also by overloading
> many tree fields (e.g. TREE_TYPE).  This makes cleaning up some fields
> in the existing tree structures a tough job.

I agree.  Many of these things should not be trees at all, and others 
are indeed abused in odd ways.  CodeSourcery has been pitching projects 
involving improving the G++ data structures at people for years. 
Overall, we (not just CodeSourcery, the whole community) have had some 
mild succsess in cleaning things up, though there's definitely more to do.

> G++ also needs to define a lot of language-specific tree nodes because
> it wants a representation that is close to the source code. 

I think that's a bit of a stretch.  In theory, we could always have just 
one tree code for CXX_TREE and then some other discriminator.  The truth 
is that if we made the things that need not be trees not be trees, there 
wouldn't be very many C++-specific tree codes.

There are actually notable advantages of using the same representation 
in the front-end and middle-end in that we are able to reuse data 
structure -- and even some code -- between the layers.  The problem is 
that we aren't clear about which layer is which, and what the rules are.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304