This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch]: PR target/27789 attribute handling fallout from DECL_INITIAL changes
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Danny Smith <dannysmith at clear dot net dot nz>
- Cc: GCC-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 08 Jun 2006 11:18:51 -0700
- Subject: Re: [Patch]: PR target/27789 attribute handling fallout from DECL_INITIAL changes
- References: <000001c68ae6$52116260$0e6d65da@anykey>
Danny Smith wrote:
> The check
> that really needs validating for dllimport is DECL_REALLY_EXTERN.
Yes, that sounds right.
> if we wait until then In order to ensure that the initialization of a
> dllmport always outputs an error message, I have added a check for
> initialization in cp/decl.c:start_decl, right after we handle the decl
> attributes.
Will this cause problems with the static data member case you mentioned
earlier? Or, do those go through grokfield, rather than start_decl?
> + if (TARGET_DLLIMPORT_DECL_ATTRIBUTES && DECL_DLLIMPORT_P (decl)
> + && initialized)
Why check TARGET_DLLIMPORT_DECL_ATTRIBUTES here? I would just say
(initialized && DECL_DLLIMPORT_P (decl))
If we want to optimize, we should put the TARGET_DLLIMPORT check into
DECL_DLLIMPORT_P itself.
With that minor tweak, and assuming static data members work, the C++
change is OK.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713