On Tue, 2005-05-17 at 10:46 -0700, Richard Henderson wrote: > On Tue, May 17, 2005 at 01:08:29PM -0400, Daniel Berlin wrote: > > This is probably going to hurt, and will require things like using > > FIELD_DECL_<blah> macros for FIELD_DECL's, TYPE_DECL_<blah> macros for > > TYPE_DECL's, etc, instead of using DECL_<blah> on both for some fields. > > Can you be more specific on which fields this will be true for? > I'm working this out as i write this, actually, by auditing code through aborts.
It looks like mainly DECL_FIELD_CONTEXT not being accessible as DECL_CONTEXT, at least for FIELD_DECL. I haven't looked heavily at TYPE_DECL yet. > > > Before i go down this path (because it is a long hard road), does anyone > > have any serious objection to having to use properly named macros to > > access the trees? This will probably add more code in some places that > > trees all DECL's the same, since they won't be the same anymore, except > > for the really really shared bits (again, UID comes to mind). > > Depending on what field, yes, I'll object. There should be a "minimal > decl" for which the "normal" decl stuff should belong to. DECL_ALIGN, > for instance. Yes, i plan on having a common part between the two decls. I'm talking more about fields that you *can* access right now in a FIELD_DECL (for example) without using the macros that do FIELD_DECL_CHECK, and there is some other macro that *does* do a FIELD_DECL check and accesses the same field. The main case i've hit so far is DECL_CONTEXT, which is also DECL_FIELD_CONTEXT, and my current thinking is that in a FIELD_DECL will be only accessible through DECL_FIELD_CONTEXT (unless we want to "re-merge" these two fields again and throw it in the common part, and always call it DECL_CONTEXT). > > > But you probably shouldn't have been doing that in the first place :) > > Disagree. You disagree, for example, that you shouldn't be using DECL_CONTEXT on FIELD_DECL? I'm curious why (unlesss it's because you believe there is no reason to separate field context and context, of course :P).