This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH to C++ visibility for 21764 and 19238
- From: Richard Henderson <rth at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 21 Mar 2006 09:22:09 -0800
- Subject: Re: PATCH to C++ visibility for 21764 and 19238
- References: <441F70A6.8050202@redhat.com>
On Mon, Mar 20, 2006 at 10:19:02PM -0500, Jason Merrill wrote:
> The problem in 19238 was that the existing code in determine_visibility
> failed to consider function scope decls. It also failed to consider
> nested classes, so I fixed that, too.
>
> I implemented the request in 21764 by making
>
> namespace foo __attribute ((visibility ("hidden")))
> {
> ...
> }
>
> equivalent to
>
> #pragma GCC visibility push(hidden)
> namespace foo
> {
> ...
> }
> #pragma GCC visibility pop
>
> So a subsequent namespace extension will not be affected by it. This
> seems like the right choice for namespaces, since separate
> namespace-declarations are independent; other options lead to odd
> effects from order of inclusion.
Do we check for buggy user code with mismatched push/pop across
this namespace declaration? This seems like an awful thing to
have to track down without compiler help.
And I'm not sure this extension is useful at all without ...
> + namespace foo __attribute ((visibility ("hidden")))
> + {
> + int f() { }
> + void g();
> + template <typename T> void t() { }
> + class A
> + {
> + void m ();
> + };
> + }
> +
> + namespace foo
> + {
> + void h() {}
> + }
... h being hidden?
Inclusion order is surely fixed by making sure that a header that
defines namespace foo is included before any other reference to
foo in the other headers.
r~