------- Comment #24 from amylaar at gcc dot gnu dot org 2007-02-05 19:26 ------- (In reply to comment #18) > It was argued in PR 29323 that it was incorrect to mark functions > that don't bind locally with TREE_NOTHROW. > > I'm not sure whether it's valid at the language level to replace > a function that can't throw with one that can.
Remember that the determination if the function can throw or not is made by analyzing the rtl of the function. I.e. there might have been a throw statement in the source, which was optimized away, so that the compiler can then determine that the function does not actually throw. Thus, TREE_NOTHROW can depend on how good the compiler is at solving specific instances of the halting problem. These might involve mathematical theorems that are yet unproven, but might be in the future so that a funture compiler can make use of it. Thus, if you require that a function that can't throw can't be replaced by one that can, you won't be able to decide if the program is valid till the mathematical theorem is either proven or disproven. Moreover, if, as the languguage level, you consider the C or C++ standard, we can't actually replace functions in first place. If that is what you want, you can use the appropriate visibility attribute in the delacation, and save a lot of overhead for each function call. If you want the function to be replacable, but don;t want the overhead of it being consider potentially throwing, you can again express this with the appropriate attribute in the declaration. > > > Assuming that the changes in TREE_NOTHROW and emission of exception > > information make sense, what solution would you implement for HP-UX 10? If the affected library functions in fact are not supposed to be replaced by functions that can throw, adding declarations with nothrow attribute will get you the performance back for the callers. It would also solve the immediate problem of the excess EH information for the function definitions, although I agree that we generally shouldn't emit it when we can reasonably determine that the actual function definition doesn't throw, even when the declaration says that it may. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487
