------- Comment #13 from dave at hiauly1 dot hia dot nrc dot ca 2007-02-03 02:46 ------- Subject: Re: Shared libstdc++ fails to link
> ------- Comment #12 from pinskia at gcc dot gnu dot org 2007-02-03 02:08 > ------- > > If a function in a module can't throw, then we don't need EH exception data > > for it. > Only if the use specifically marked it as such. Really you can replace the > weak function with any other function which then just throws. I don't see how > that patch is wrong, it makes the throw optimization the same as the inliner > and const/pure optimizations. Now emitting EH info for the function itself is > a different story. Right now the use TREE_NOTHROW is two fold, it is used in > dwarf2out to ask the question does the function compiling actually throw, and > every where else does this function decl throw. > > At one point, the meaning was only the last one and then Paolo Bonzini changed > it to mean the first one too (though in a sense Richard's patch needs to be > updated to just not set TREE_NOTHROW for the binds local case). Still stand by my comment. If a weak function is replaced, the EH data used in handling any exception will be that for the replacement. So if a function is marked as nothrow or analysis indicates it can't throw, then we don't need to output EH data for it. While the GNU linker may be able to eliminate unnecessary EH data, this isn't the case for the HP linker. In HP-UX 11, we don't use SDEf symbols instead of COMDAT sections (subspaces). I'm fairly certain in this case that we end up with multiple function copies and EH data. The two fold use of TREE_NOTHROW is the problem. I haven't looked at this in detail but I would have thought that a combination of the first meaning together with knowing whether a function can be overloaded/replaced would be sufficient to determine whether this function might throw. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
