public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/98785] New: _Unwind_ForcedUnwind going through a non-empty exception specification
@ 2021-01-22  1:25 i at maskray dot me
  2021-01-22 11:47 ` [Bug libstdc++/98785] " redi at gcc dot gnu.org
  2021-01-22 13:28 ` redi at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: i at maskray dot me @ 2021-01-22  1:25 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98785

            Bug ID: 98785
           Summary: _Unwind_ForcedUnwind going through a non-empty
                    exception specification
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: i at maskray dot me
  Target Milestone: ---

gcc/testsuite/g++.dg/eh/forced3.C says forced unwinding calls std::unexpected
going through a throw() function.

gcc/testsuite/g++.dg/eh/forced4.C says forced unwinding does not call
std::unexpected going through a throw(int) function.

The behavior looks strange: if we consider forced unwinding a special exception
type, both throw() and throw(int) should catch it.


Note: for nothrow, GCC emits minimum amount of .gcc_except_table section.
forced unwinding calls std::terminate.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/98785] _Unwind_ForcedUnwind going through a non-empty exception specification
  2021-01-22  1:25 [Bug libstdc++/98785] New: _Unwind_ForcedUnwind going through a non-empty exception specification i at maskray dot me
@ 2021-01-22 11:47 ` redi at gcc dot gnu.org
  2021-01-22 13:28 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-22 11:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98785

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Fangrui Song from comment #0)
> The behavior looks strange: if we consider forced unwinding a special
> exception type, both throw() and throw(int) should catch it.


It's not strange if you consider throw() to be noexcept(true) and throw(int) as
similar to noexcept(false).

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/98785] _Unwind_ForcedUnwind going through a non-empty exception specification
  2021-01-22  1:25 [Bug libstdc++/98785] New: _Unwind_ForcedUnwind going through a non-empty exception specification i at maskray dot me
  2021-01-22 11:47 ` [Bug libstdc++/98785] " redi at gcc dot gnu.org
@ 2021-01-22 13:28 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2021-01-22 13:28 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98785

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
FWIW I think this belongs to the libgcc or c++ components, as
_Unwind_ForcedUnwind is not defined in libstdc++.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-01-22 13:28 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-22  1:25 [Bug libstdc++/98785] New: _Unwind_ForcedUnwind going through a non-empty exception specification i at maskray dot me
2021-01-22 11:47 ` [Bug libstdc++/98785] " redi at gcc dot gnu.org
2021-01-22 13:28 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).