From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16637 invoked by alias); 7 Apr 2006 00:55:29 -0000 Received: (qmail 16554 invoked by uid 48); 7 Apr 2006 00:55:26 -0000 Date: Fri, 07 Apr 2006 00:55:00 -0000 Message-ID: <20060407005526.16553.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/10591] PCH breaks anonymous namespaces In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "geoffk at gcc dot gnu dot org" 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 X-SW-Source: 2006-04/txt/msg00585.txt.bz2 List-Id: ------- Comment #23 from geoffk at gcc dot gnu dot org 2006-04-07 00:55 ------- (In reply to comment #22) > The PCH problem with get_file_function_name is independent of the question of > giving anonymous namespace members internal linkage. We still need to give > them distinct names; we are giving up on address comparison of type_infos > because of problems with plugins. If you're giving up address comparison on type_info, you still have to find a way where two typeinfo objects with the same C++ name can be different, due to this example: A shared object contains class A { }; class B __attribute__((visibility("hidden"))) : class A { }; void f () { throw new B(); } A main program contains: class A { }; extern void f(); class B __attribute__((visibility("hidden"))) { int x; }; // not an A int main() { try { f(); } catch (B * p) { abort(); } catch (A * p) { exit (0); } abort(); } This program should not abort, because the 'B' in the main program is not the same as the 'B' in the dylib. My suggestion would be to include &__dso_handle in the typeinfo for objects with hidden visibility, and also compare that. Now, if you're doing this for visibility, you can also do it for anonymous namespaces. Just find any address in the translation unit that contains the anonymous namespace (hey, how about the address of the typeinfo itself?), and consistently include that address in the typeinfo, and compare that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10591