From comment #15 in upstream: "Then, why what is this PR is about in the first
https://bugzilla.novell.com/show_bug.cgi?id=256642 ------- Comment #9 from llunak@novell.com 2007-04-24 03:30 MST ------- I'd prefer if this was fixed upstream, as this is clearly a bug. My guess at why it is so difficult to explain in the upstream bugreport is because you libstdc++ people go too much used to this and don't know what -fno-exceptions really does. place? -fno-exceptions turns try/catch into macros with specified semantics." - This is not true. It's libstdc++ that turns the keywords into macros, with semantics that may be fine for libstdc++ but that are dangerous in general (as with our update). Using -fno-exceptions on its own disables exceptions support and if it is used anywhere in the code it aborts the compilation with an error message (just like e.g. if you asked for strict ANSI compliance and used GNU extensions). You can see the difference if you compile the testcase with -fno-exceptions and either leave or remove the "#include <memory>". Libstdc++ silently changes semantics of the C++ keywords. I'll try to sum this up in the upstream report, but if this is not enough to convince upstream, please do so for us. As far as I can say the upstream suggestion for the fix is the same like mine (mine actually has a bug in "define __catch catch", it should be "#define __catch(X) catch(X)"). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.