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
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
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
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
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
--- 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
--- 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
--- 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
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |libstdc++
Ever
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
15 matches
Mail list logo
