------- Comment #36 from pcarlini at suse dot de 2007-04-27 12:04 ------- Humm, probably, however, I'm finally getting Gaby's point about the front-end involvement (sorry, I wasn't really paying attention to this PR until a few days ago): if we implement something like Howard's change we would certainly solve many problems *but* we would regress in another area: some general user code (thus freely using try/catch blocks) would not compile anymore when -fno-exceptions is passed on the command line. I see why some people would not consider that a problem, because they are removing by hand try/catch from translation units not meant to use exceptions, but I consider that a defect anyway, or, at least, a very substantive change of behavior which must be seriously weighted. Instead, ideally, one would like to compile the *very same code* and just not generate the heavy exception machinery when -fno-exceptions is passed on the command line. I think that idea exists in the current design of the macros, maybe incompletely implemented (e.g., at least one library header must be included), and it's nice, very nice, by itself.
Now, that idea in principle it's perfectly doable, the only problem is that the front-end must be changed, isn't something we can do completely at the library level. Alternately, probably better in order not to break existing code, a new option could be added, which, essentially, at variance with the current -fno-exceptions, would parse try/catch normally, and then finally simply skip the semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
