[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 --- Comment #18 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Apr 1 17:28:29 2014 New Revision: 208991 URL: http://gcc.gnu.org/viewcvs?rev=208991root=gccview=rev Log: Core DR 475 PR c++/41174 PR c++/59224 * libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions. * libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception) (__cxa_allocate_exception): Don't set it here. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught4.C Modified: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/eh/uncaught1.C branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_alloc.cc branches/gcc-4_7-branch/libstdc++-v3/libsupc++/eh_throw.cc
[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jan 27 13:57:39 2014 New Revision: 207129 URL: http://gcc.gnu.org/viewcvs?rev=207129root=gccview=rev Log: Core DR 475 PR c++/41174 PR c++/59224 * libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions. * libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception) (__cxa_allocate_exception): Don't set it here. Added: trunk/gcc/testsuite/g++.dg/eh/uncaught4.C Modified: trunk/gcc/testsuite/g++.dg/eh/uncaught1.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/eh_alloc.cc trunk/libstdc++-v3/libsupc++/eh_throw.cc
[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Jan 27 13:58:48 2014 New Revision: 207131 URL: http://gcc.gnu.org/viewcvs?rev=207131root=gccview=rev Log: Core DR 475 PR c++/41174 PR c++/59224 * libsupc++/eh_throw.cc (__cxa_throw): Set uncaughtExceptions. * libsupc++/eh_alloc.cc (__cxa_allocate_dependent_exception) (__cxa_allocate_exception): Don't set it here. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught4.C Modified: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/eh/uncaught1.C branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_alloc.cc branches/gcc-4_8-branch/libstdc++-v3/libsupc++/eh_throw.cc
[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #17 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.8.3/4.9.
[Bug libstdc++/41174] uncaught_exception always returns true
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Blocks||59224 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Known to fail||
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #14 from paolo dot carlini at oracle dot com 2010-01-08 19:14 --- I'm asking Rth to have a look to this one, apparently unrelated to DR Core 475. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org Severity|trivial |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #12 from wwashby at earthlink dot net 2009-08-29 11:27 --- (In reply to comment #11) (In reply to comment #10) I'm not sure that this applies in this situation. An instance of BadE is constructed because it is thrown, but BadE::BadE does not [exit] via an uncaught exception. It both throws and catches an exception, and then returns normally. There is still an uncaught exception when BadE::BadE exits, but it is the one that caused BadE to be constructed, not the one that BadE::BadE has thrown (and caught). No, in [except.handle]/16 the standard says The exception being handled is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. You cannot swallow exceptions in a constructor's function-try-block, they will be rethrown. 1,000 apologies, of course you are right; my own code and shows that (blush). Maybe uncaught_exception assumes that the throw BadE will succeed and doesn't notice that the BadE object is not fully constructed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #13 from wwashby at earthlink dot net 2009-08-29 12:50 ---
(In reply to comment #12)
...
Maybe uncaught_exception assumes that the throw BadE will succeed and doesn't
notice that the BadE object is not fully constructed?
Apparently that is the case. Here's another test case where throw fails to
throw an exception:
#include cstdlib
#include iostream
#include exception
void ae()
{
std::cerr At exit std::uncaught_exception() = std::boolalpha
std::uncaught_exception() .\n;
}
struct NoE {
NoE() { std::exit(0); }
};
int main()
{
std::atexit(ae);
throw NoE();
}
/* Output:
At exit std::uncaught_exception() = true.
*/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
-- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c++ |libstdc++ Ever Confirmed|0 |1 GCC build triplet|same| GCC host triplet|Microsoft Windows XP Home | |Edition, x86 Family 16 Model| |2 Steppin | GCC target triplet|same| Known to fail||4.3.4 4.4.1 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-08-27 10:37:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #6 from paolo dot carlini at oracle dot com 2009-08-27 10:51 --- Is this related to PR 37477? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #7 from redi at gcc dot gnu dot org 2009-08-27 11:37 --- (In reply to comment #6) Is this related to PR 37477? It looks like a slightly different issue. PR 37477 relates to when uncaught_exception() stops being true and fixing it might need to wait for the resolution to core issue 475. This bug relates to when uncaught_exception() starts being true, and I don't think it depends on issue 475 (although it might make sense to wait for a resolution anyway.) The table in issue 475 would show today's GCC as 1 1 1 1 ABRT and I believe that first 1 is wrong and is the root cause of this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #8 from paolo dot carlini at oracle dot com 2009-08-27 11:59 --- As a general rule, if we are sure about the dependency on a DR, we suspend the PR and remember the DR # in the Summary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #9 from redi at gcc dot gnu dot org 2009-08-27 12:18 --- (In reply to comment #5) I think the problem is that the uncaught_exception() is true as soon as the memory for the exception has been allocated, but if the exception's copy constructor is elided then happens before entering the exception's constructor. If the exception constructor throws another exception then uncaughtExceptions goes to 2, and never goes back to zero. After re-reading [except.throw] and [except.terminate] I think it is OK to elide the copy of the thrown object into the exception object here: throw e(); This means that uncaught_exception() can be true in the call e::e() *But* if the copy is elided and e::e() throws then std::terminate() should be called. This means the OP's testcase and my one in comment #5 should terminate, rather than exiting normally with std::uncaught_exception()==true This is because of the following in [except.terminate]/1 when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (15.1), calls a function that exits via an uncaught exception, 141 141) For example, if the object being thrown is of a class with a copy constructor, std::terminate() will be called if that copy constructor exits with an exception during a throw. Now, either (A) e::e() happens before completing evaluation of the expression to be thrown and uncaught_exception() should be false during e::e() or (B) the copy is elided and e::e() happens after evaluating completing evaluation. In this case, uncaught_exception() should be true during e::e() but if it exits with an exception then std::terminate() should be called. GCC elides the copy, but does not call std::terminate() if e::e() exits with an exception. I don't think this interpretation will be changed by DR 475 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #10 from wwashby at earthlink dot net 2009-08-27 14:27 --- (In reply to comment #9) ... when the exception handling mechanism, after completing evaluation of the expression to be thrown but before the exception is caught (15.1), calls a function that exits via an uncaught exception, 141 141) For example, if the object being thrown is of a class with a copy constructor, std::terminate() will be called if that copy constructor exits with an exception during a throw. ... I'm not sure that this applies in this situation. An instance of BadE is constructed because it is thrown, but BadE::BadE does not [exit] via an uncaught exception. It both throws and catches an exception, and then returns normally. There is still an uncaught exception when BadE::BadE exits, but it is the one that caused BadE to be constructed, not the one that BadE::BadE has thrown (and caught). -- wwashby at earthlink dot net changed: What|Removed |Added CC||wwashby at earthlink dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
[Bug libstdc++/41174] uncaught_exception always returns true
--- Comment #11 from redi at gcc dot gnu dot org 2009-08-27 15:19 --- (In reply to comment #10) I'm not sure that this applies in this situation. An instance of BadE is constructed because it is thrown, but BadE::BadE does not [exit] via an uncaught exception. It both throws and catches an exception, and then returns normally. There is still an uncaught exception when BadE::BadE exits, but it is the one that caused BadE to be constructed, not the one that BadE::BadE has thrown (and caught). No, in [except.handle]/16 the standard says The exception being handled is rethrown if control reaches the end of a handler of the function-try-block of a constructor or destructor. You cannot swallow exceptions in a constructor's function-try-block, they will be rethrown. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174
