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 Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Date: Tue, 17 May 2005 15:13:36 -0400
- Subject: Re: My evil plans for the next few weekends
- References: <10505171859.AA21719@vlsi1.ultra.nyu.edu>
On Tue, 2005-05-17 at 14:59 -0400, Richard Kenner wrote:
> The main case i've hit so far is DECL_CONTEXT, which is also
> DECL_FIELD_CONTEXT
>
> Are there any other cases? Offhand, I can't think of another DECL field
> that's shared by only a subset of DECLs.
An example is DECL_INITIAL vs DECL_QUALIFIER. You could theoret
There are shared *fields*, but the macros are stricter than DECL_CHECK
(IE FUNCTION_DECL_CHECK or TYPE_DECL_CHECK) so they can't be accessed
through the wrong macro.
For example, FIELD_DECL and VAR_DECL both use bit_field_flag, for two
different purposes, but the DECL_IN_TEXT_SECTION macro checks to make
sure the node is a VAR_DECL before you can access it as a VAR_DECL, and
the DECL_BIT_FIELD macro makes sure the node is a FIELD_DECL before you
can access it on a FIELD_DECL.
Thus, there is no way we could be using that field unsafely, unless we
were doing it bare (ie tree->decl.bit_field_flag)
I audited the other ones for FIELD_DECL, and most of the "unsafe" macros
(IE just doing DECL_CHECK) are only used in one or two source files, and
looking at the context makes it clear they won't be called on FIELD_DECL
in those cases (IE they are inside if (code == FUNCTION_DECL) or
whatever).
The only ones that appear in more than a few places are DECL_REGISTER vs
DECL_PACKED, DECL_CONTEXT vs DECL_FIELD_CONTEXT, and DECL_INITIAL vs
DECL_QUALIFIER.
--Dan