From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18641 invoked by alias); 5 Feb 2007 03:06:35 -0000 Received: (qmail 18581 invoked by alias); 5 Feb 2007 03:06:16 -0000 Date: Mon, 05 Feb 2007 03:06:00 -0000 Message-ID: <20070205030616.18580.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/29487] Shared libstdc++ fails to link In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mark at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-02/txt/msg00650.txt.bz2 ------- Comment #17 from mark at codesourcery dot com 2007-02-05 03:06 ------- Subject: Re: Shared libstdc++ fails to link dave at hiauly1 dot hia dot nrc dot ca wrote: > Unwind data. We're talking about functions compiled in the > current object. OK. I'm not sure it matters, but if these functions don't throw exceptions, I don't understand why we're not marking them TREE_NOTHROW. I suspect there's something that I'm just not following. The fact that linker semantics allow you to replace a function at the object level do not make it valid at the language level. So, for example, I would expect: void f () throw () {} and: void g() {} to both be TREE_NOTHROW, independent of linkage, weakness, etc. Certainly, not marking such functions as TREE_NOTHROW will inhibit optimization of their callers, which seems bad. Why aren't the functions being marked TREE_NOTHROW? > There are numerous "one-only/weak" functions which don't bind locally > in libstdc++. Previously, *ALL* these functions were determined to be > nothrow and no unwind data was emitted for them. Now, unwind > data is being emitted because these functions don't bind locally. > This breaks the HP-UX 10 DWARF2 unwind implementation (obviously a > latent bug) because of the relocation issue mentioned above. I understand that this is a latent bug in the HP-UX linker. To be honest, I'm less concerned about HP-UX 10.10 per se than about the possible bloat on other targets. (HP-UX 10 is not a primary or secondary target.) At the same time, I certainly don't want to gratuitously break any target. Assuming that the changes in TREE_NOTHROW and emission of exception information make sense, what solution would you implement for HP-UX 10? Use SJLJ exception handling? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487