------- Comment #19 from mark at codesourcery dot com 2007-02-05 05:40 ------- Subject: Re: Shared libstdc++ fails to link
dave at hiauly1 dot hia dot nrc dot ca wrote: > ------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-05 > 04:02 ------- > Subject: Re: Shared libstdc++ fails to link > >> 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. > > See the testcase for PR 29323 and the initial problem description. Thanks. The fact that the declaration is explicitly declare weak seems somewhat persuasive. C++ has no notion of weak symbols, so once you declare a function weak, you're outside the standard anyhow, and it's reasonable to say that you can replace such a function with one of the same type. However, that doesn't mean that the check for binds_local makes sense. In particular, a COMDAT template instantiation may not bind locally (IIUC), but it's invalid to replace the template instantiation with one that behaves differently. So, it sounds like the change that's been made unduly pessimizes C++ template instantiations, which would plausibly result in the behavior you're seeing. And, as you say, even for explicitly weak functions, it doesn't make sense to emit EH unwind information if the functions never throw. That's just a pessimization. So, as has been said elsewhere, that suggests that -- for the weak function case -- we need to distinguish "body of this function needs unwind information" from "callers of this function must assume it throws exceptions". Frankly, my inclination would be to just declare that in GNU C++, replacing a "weak" function with an implementation that throws more exceptions than the version in the current translation unit is invalid, no diagnostic required. This doesn't seem like a case worth twisting our internal representations around to support. >> 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? > > Yes, config.gcc could be modified to force SJLJ exception handling. > Of course, I'm hoping for a better fix to PR 29323. Right. I've CC'd Richard G on the PR. Richard, what are your thoughts? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
