From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17233 invoked by alias); 5 May 2004 08:26:43 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 17222 invoked by uid 48); 5 May 2004 08:26:42 -0000 Date: Wed, 05 May 2004 08:26:00 -0000 Message-ID: <20040505082642.17221.qmail@sources.redhat.com> From: "bryner at brianryner dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040418032536.15000.bryner@brianryner.com> References: <20040418032536.15000.bryner@brianryner.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug other/15000] Support setting the default symbol visibility for ELF X-Bugzilla-Reason: CC X-SW-Source: 2004-05/txt/msg00390.txt.bz2 List-Id: ------- Additional Comments From bryner at brianryner dot com 2004-05-05 08:26 ------- (In reply to comment #24) > It's definitely the case that attributes for classes are processed inside > outwards so I've reverted back to the old patch which works in the opposite > direction. I should have a new patch with the #pragma and nested classes > inheriting visibility by tonight. The old patch also works "inside outwards". That is, prehandle_attributes is not going to be called for a class until the entire class has been parsed, which implies that a nested class has already been finished off. After the class attributes are handled, it iterates over the member decls again (i.e. check_field_decls) which allows the class attributes to be taken into account for each member decl. One reason for that, I think, is that attributes can come at the end of a declaration, like this example from the documentation: struct foo { int x; char a, b, c, d; } __attribute__((packed)); You can see that in the analogous situation for visibility: struct foo { struct bar { ... }; } __attribute__((visibility ("hidden"))); it would not be possible to know the outer class visibility when processing foo::bar. So I see a couple of ways to address this: 1. Say that the visibility attribute can only be at the beginning of a class/struct declaration, and arrange to handle that attribute _before_ we begin parsing class members. I don't think there is any existing mechanism for handling attributes at this stage, so we'd have to create something new. 2. Recursively reset DECL_VISIBILITY for members of inner classes once we reach the end of a top-level class definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15000