This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH RFC: PR 33094: Test DECL_INITIAL in make_rtl_for_nonlocal_decl
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 17 Aug 2007 17:08:53 -0700
- Subject: Re: PATCH RFC: PR 33094: Test DECL_INITIAL in make_rtl_for_nonlocal_decl
- References: <m3d4xmqj5c.fsf@localhost.localdomain>
Ian Lance Taylor wrote:
> namespace
> {
>
> template <typename T>
> class A
> {
> virtual T f1() { return c; }
> static const T c = 0;
> };
Thanks for the analysis!
> All those steps seem reasonable. If the anonymous namespace is
> removed from the test case, all is well because DECL_EXTERNAL is set.
> When using the anonymous namespace, DECL_EXTERNAL is not set.
That seems wrong. This declaration is not a definition. For example, a
reference to &A<int>::c from within this file should be unresolved at
link-time. (The standard says that this is an invalid thing to do; I
don't know if it says that a diagnostic is required.)
> /* If this static data member is needed, provide it to the
> back end. */
> if (DECL_NOT_REALLY_EXTERN (decl) && decl_needed_p (decl))
> DECL_EXTERNAL (decl) = 0;
I think DECL_NOT_REALLY_EXTERN is the wrong test here, now that things
with anonymous namespaces get ELF local linkage. The confusion here is
that the language says they have external linkage; it's an optimization
that, in generating object files, we now give them ELF local linkage.
There's no such thing as a "static" forward declaration (e.g., "static
int i;" is a definition, not a declaration that "i" exists) -- but now
we've essentially created such a thing.
I think DECL_EXTERNAL has historically only applied to TREE_PUBLIC
things -- but probably that's the best way to represent that. In other
words, interpret DECL_EXTERNAL as "there is no definition of this entity
in this translation unit (yet)".
> The DECL_NOT_REALLY_EXTERN flag is only set when using an anonymous
> namespace. It happens in constrain_visibility:
I think that's wrong. I think we should leave DECL_NOT_REALLY_EXTERN
clear until/unless we actually encounter a definition. I don't think
constrain_visibility should have any effect on DECL_NOT_REALLY_EXTERN,
given the above.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713