This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: My evil plans for the next few weekends
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Richard Henderson <rth at redhat dot com>
- Cc: Zack Weinberg <zack at codesourcery dot com>, Gcc Mailing List <gcc at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 17 May 2005 14:10:48 -0400
- Subject: Re: My evil plans for the next few weekends
- References: <1116349709.8102.91.camel@linux.site> <20050517174601.GA945@redhat.com>
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).