This is the mail archive of the gcc@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: We're out of tree codes; now what?


"Doug Gregor" <doug.gregor@gmail.com> writes:

> Of course, one could use TREE_CODE to see through the difference
> between these two, e.g.,
> 
>   #define TREE_CODE(NODE)
>     ((enum tree_code) (NODE)->base.code == LANG_TYPE?
>         (enum tree_code)((TYPE_LANG_SPECIFIC (NODE)->base.subcode +
> LAST_AND_UNUSED_TREE_CODE))
>         : (enum tree_code) (NODE)->base.code)
> 
> Then, the opposite for TREE_SET_CODE:
>   #define TREE_SET_CODE(NODE, VALUE)
>      ((VALUE) >= LAST_AND_USED_TREE_CODE)?
>         ((NODE)->base.code = LANG_TYPE, get_type_lang_specific
> (NODE)->base.subcode = (VALUE) - LAST_AND_USED_TREE_CODE)
>      : ((NODE)->base.code = (VALUE))

Somehow I didn't quite see that you were proposing a change to
TREE_CODE itself.  It doesn't make sense to change TREE_CODE for
something which is language specific: that would affect the whole
compiler.  But I think it would be reasonable to introduce
LANG_TREE_CODE along the lines of what you wrote above, and use that
only in the frontend code.

Ian


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