[Bug libstdc++/41174] uncaught_exception always returns true

[Bug libstdc++/41174] uncaught_exception always returns true

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=207129&root=gcc&view=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

[jason at gcc dot gnu.org]

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=207131&root=gcc&view=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

[jason at gcc dot gnu.org]

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

[jason at gcc dot gnu.org]

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=208991&root=gcc&view=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

[paolo dot carlini at oracle dot com]

------- 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

[wwashby at earthlink dot net]

------- 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

[wwashby at earthlink dot net]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[Bug libstdc++/41174] uncaught_exception always returns true

[wwashby at earthlink dot net]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[redi at gcc dot gnu dot org]

------- 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

[paolo dot carlini at oracle dot com]

------- 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

[redi at gcc dot gnu dot org]

-- 

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|0000-00-00 00:00:00         |2009-08-27 10:37:03
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41174