stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (STDCXX-998) add throw() exception specification to all non-throwing functions
Date Sat, 26 Jul 2008 21:36:31 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12617218#action_12617218
] 

sebor edited comment on STDCXX-998 at 7/26/08 2:34 PM:
--------------------------------------------------------------

Gcc's attribute [{{nothrow}}|http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-1603]
(first introduced in gcc 3.3) is even better for functions that cannot throw because, unlike
the empty exception specification, it lets the compiler avoid checks for exceptions that it
must assume may be thrown from functions declared without {{throw()}} and called from functions
declared with the attribute, and calling {{std::unexpected()}} just in case an exception is
thrown.

The attribute is preferrable for nothrow functions that must call others that may not have
an exception specification (e.g., in generic code). The empty {{throw()}} specification is
appropriate for nothrow functions that don't call any such functions (such as leaf procedures).

For example, for the following code gcc 4.1 generates the assembly below (at {{-O2}}):

{code}
void f ();
void g () throw () { f (); }
void h () __attribute__ ((nothrow));
void h () { f (); }
{code}

{code}
        .type   _Z1hv, @function
_Z1hv:
        jmp     _Z1fv

        .type   _Z1gv, @function
_Z1gv:
        subq    $8, %rsp
        call    _Z1fv
        addq    $8, %rsp
        ret

        addq    $1, %rdx
        movq    %rax, %rdi
        je      .L5
        call    _Unwind_Resume
.L5:
        call    __cxa_call_unexpected
{code}

      was (Author: sebor):
    Gcc's attribute [{{nothrow}}|http://gcc.gnu.org/onlinedocs/gcc-3.3.6/gcc/Function-Attributes.html#index-g_t_0040code_007bnothrow_007d-function-attribute-1603]
(first introduced in gcc 3.3) is even better for functions that cannot throw because, unlike
the empty exception specification, it lets the compiler avoid checks for exceptions that it
must assume may be thrown from functions declared without {{throw()}} and called from functions
declared with the attribute, and calling {{std::unexpected()}} just in case an exception is
thrown. For example, for the following code gcc 4.1 generates the assembly below (at {{-O2}}):

{code}
void f ();
void g () throw () { f (); }
void h () __attribute__ ((nothrow));
void h () { f (); }
{code}

{code}
        .type   _Z1hv, @function
_Z1hv:
        jmp     _Z1fv

        .type   _Z1gv, @function
_Z1gv:
        subq    $8, %rsp
        call    _Z1fv
        addq    $8, %rsp
        ret

        addq    $1, %rdx
        movq    %rax, %rdi
        je      .L5
        call    _Unwind_Resume
.L5:
        call    __cxa_call_unexpected
{code}
  
> add throw() exception specification to all non-throwing functions
> -----------------------------------------------------------------
>
>                 Key: STDCXX-998
>                 URL: https://issues.apache.org/jira/browse/STDCXX-998
>             Project: C++ Standard Library
>          Issue Type: Improvement
>          Components: Build and Installation
>    Affects Versions: 4.2.1
>            Reporter: Martin Sebor
>            Priority: Critical
>             Fix For: 4.2.2
>
>         Attachments: uninit_fill.ipf.s, unint_fill_nothrow.ipf.s
>
>   Original Estimate: 6h
>  Remaining Estimate: 6h
>
> When a compiler cannot determine whether a function declared without an explicit exception
specification may throw an exception or not (e.g., because the compiler/optimizer doesn't
have access to the definition of the function) it must assume that the function may throw
and may need to generate suboptimal code as a result.
> Compilers often assume that even inline functions that can be proven not to throw exceptions
may throw unless they are declared with the empty exception specification and generates suboptimal
code as a result. For example, HP aCC 6 assumes that {{S::S()}} in the code below may throw
> and fails to optimize the catch block away, generating object code 2.5 times the size
bigger than necessary. (Note that gcc 3.4 on IPF generates optimal code in this case).
> To help compilers generate optimal code we should make use of the empty exception specification
on all functions that cannot throw exceptions, including those declared explicitly or implicitly
{{inline}}.
> {code}
> #include <new>
> struct S {
>     int i;
>     S () /* throw () */: i () { }
> };
> void uninit_fill (S *a, S *b)
> {
>     S *p = a;
>     try {
>         for ( ; p != b; ++p)
>             new (p) S ();
>     }
>     catch (...) {
>         while (p-- != a)
>             p->~S ();
>         throw;
>     }
> }
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message