On Sat, Nov 22, 2014 at 12:49 AM, Joseph Myers <jos...@codesourcery.com> wrote: > On Fri, 21 Nov 2014, Andrew MacLeod wrote: > >> The biggest issue is what to do with fields which can be either a type or a >> tree... ie TREE_VALUE() of a TREE_LIST can be a type, as can a TREE_VEC >> element or a DECL_CONTEXT. I think the DECL_INITIAL field is overloaded and >> can sometimes be a type, and this was recently introduced to >> TARGET_STATIC_CHAIN. I suspect the compilation process will identify others. >> >> Looking primarily at TREE_LIST first (which can be a mixed list of trees and >> types), the question is how to generally handle this situation > > TREE_LIST should die (with the typical replacement being vec<something>); > most lists do not need all the overhead of individually allocated objects > with (code, flags, type, chain, value, purpose). Probably TREE_VEC too.
Note that there is nothing wrong with TREE_LIST or TREE_VEC if they were based off tree_base only. That they inherit from tree_common is the bug to fix - either by not using TREE_LIST or TREE_VEC from the users that use fields from tree_common or tree_typed or by adjusting those users to not need those fields. > That doesn't answer your question - making lists and vectors no longer > have the static type "tree" ought to be essentially independent cleanups > from making types no longer have the static type "tree", rather than being > dependencies of that. But it's a goal to keep in mind when there's a > choice of what to do about a particular TREE_LIST or TREE_VEC case. Correct. I still think that statically typing 'tree' fields that are always tree_type_common to sth like 'ttype' (following 'gassign' naming convention) is something to explore. Whether it needs turing 'tree' upside-down (get rid of the union) I am not sure. Richard. > -- > Joseph S. Myers > jos...@codesourcery.com