You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2008/07/26 23:24:31 UTC

[jira] Commented: (STDCXX-998) add throw() exception specification to all non-throwing functions

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

Martin Sebor commented on STDCXX-998:
-------------------------------------

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.