[Bug c++/53025] New: [C++11] noexcept operator depends on copy-elision

[Bug c++/53025] New: [C++11] noexcept operator depends on copy-elision

[daniel.kruegler at googlemail dot com]

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

             Bug #: 53025
           Summary: [C++11] noexcept operator depends on copy-elision
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: daniel.kruegler@googlemail.com


gcc 4.8.0 20120318 (experimental) in C++11 mode rejects the following code:

//-----
struct A {
  A() noexcept {}
  A(const A&) noexcept(false) {}
};

void a(A) noexcept {}

static_assert(!noexcept(a(A{})), ""); // Error
//-----

According to [expr.call] p4 parameter construction happens in the caller space,
therefore the copy-initialization need to respect the noexcept(false) of the
copy constructor (The same problem for a type with a corresponding
move-constructor). 

There seems to be evidence that the outcome of the test above depends on
compiler optimization (copy-elision): 

a) If we change the program slightly to the following form:

//-----
template<class T>
T&& declval() noexcept;

struct A {
  A() noexcept {}
  A(const A&) noexcept(false) {}
};

void a(A) noexcept {}

static_assert(!noexcept(a(declval<A>())), ""); // OK
//-----

The code is accepted, presumably because 12.8 p31 b3 does no longer hold. 

b) An even more convincing argument is that when adding the compiler argument

--no-elide-constructors 

the original code becomes accepted as well, thus the outcome indeed depends on
copy-elision taking place or not. The semantics of the noexcept operator
(5.3.7) are described by "potentially evaluated functions calls" and 3.2 p3
says in a note that "A constructor selected to copy or move an object of class
type is odr-used even if the call is actually elided by the implementation", so
this observable behaviour seems to be non-conforming.

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[marc.glisse at normalesup dot org]

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

Marc Glisse <marc.glisse at normalesup dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marc.glisse at normalesup
                   |                            |dot org

--- Comment #1 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-18 06:18:57 UTC ---
(In reply to comment #0)
> b) An even more convincing argument is that when adding the compiler argument
> 
> --no-elide-constructors 
> 
> the original code becomes accepted as well, thus the outcome indeed depends on
> copy-elision taking place or not. The semantics of the noexcept operator
> (5.3.7) are described by "potentially evaluated functions calls" and 3.2 p3
> says in a note that "A constructor selected to copy or move an object of class
> type is odr-used even if the call is actually elided by the implementation", so
> this observable behaviour seems to be non-conforming.

It seems you are right, because the standard gives an unusual definition of
"potentially evaluated". In English an elided function call is not potentially
evaluated as the code for it isn't even generated.

It looks like the standard may require noexcept to be computed as if there were
no elisions, but that is a code pessimization that may not be necessary (or it
may be, so we can better rely on noexcept not subtly changing when the
circumstances are just different enough that the compiler won't elide a copy).

I wonder if saving flag_elide_constructors and setting it to false in
cp_parser_unary_expression before calling cp_parser_expression, and restoring
it afterwards (like many other flags get saved, set and restored) would be
enough, or if the elision is sometimes done later.

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[marc.glisse at normalesup dot org]

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

--- Comment #2 from Marc Glisse <marc.glisse at normalesup dot org> 2012-04-21 07:45:57 UTC ---
Created attachment 27210
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27210
patch

Bootstrapped and regression tested.

Not posting it to gcc-patches yet, for several reasons:
- I have other patches (at least 3) waiting for a review,
- I am not 100% certain that this can't cause legitimate elisions to be missed
(say if something is first instantiated inside the noexcept),
- people may not like using globals that way,
- I might prefer the old behavior...

but if anyone wants to submit it, feel free.

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[daniel.kruegler at googlemail dot com]

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

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
This is just a polite reminder for some response. I'm especially interested to
hear whether there exist any reasonable doubts on the validity of the arguments
brought forward. IMO it is important to fix at, because otherwise it does have
the potential to subtly change overload selection (if noexcept is used as part
of sfinae) and other static introspection tests. I'd like to add that a related
CWG issue

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1356

was submitted for another situation where it was considered important that
exception-specification is "stable" regardless of an actual call. The new
wording suggested as of

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1351

seems clear to me to have the effect of including functions even if they are
copy-elided.
>From gcc-bugs-return-428346-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 25 06:32:50 2013
Return-Path: <gcc-bugs-return-428346-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16097 invoked by alias); 25 Aug 2013 06:32:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16072 invoked by uid 48); 25 Aug 2013 06:32:46 -0000
From: "schwab@linux-m68k.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/58239] New: [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'
Date: Sun, 25 Aug 2013 06:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: build
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schwab@linux-m68k.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status keywords bug_severity priority component assigned_to reporter
Message-ID: <bug-58239-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg01270.txt.bz2
Content-length: 2396

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX239

            Bug ID: 58239
           Summary: [4.9 regression] pretty-print.c:789: undefined
                    reference to `operator delete(void*)'
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: build
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schwab@linux-m68k.org

../../xgcc -B../../ -static-libgcc -I- -I../rts -I.
-I/usr/local/gcc/gcc-2013082
5/gcc/ada -DIN_GCC  -DUSE_LIBUNWIND_EXCEPTIONS -O2 -g -W -Wall  -o
../../gnatlin
k b_gnatl.o gnatlink.o a-except.o ali.o alloc.o butil.o casing.o csets.o
debug.o
 fmap.o fname.o gnatvsn.o hostparm.o indepsw.o interfac.o i-c.o i-cstrin.o
namet
.o opt.o osint.o output.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o
s
default.o snames.o stylesw.o switch.o system.o table.o targparm.o tree_io.o
type
s.o validsw.o widechar.o \
                    ../link.o ../targext.o ../../ggc-none.o
../../libcommon-targ
et.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a
../../../libb
acktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a
/bin/sh ./libtool --tag=GCJ   --mode=compile
/usr/local/gcc/gcc-20130825/Build/.
/gcc/gcj -B/usr/local/gcc/gcc-20130825/Build/ia64-suse-linux/libjava/
-B/usr/loc
al/gcc/gcc-20130825/Build/./gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-li
nux/lib/ -isystem /usr/ia64-suse-linux/include -isystem
/usr/ia64-suse-linux/sys
-include    -funwind-tables -fclasspath-fbootclasspath=../../../libjava/classp
ath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2  -c -o
gnu/j
ava/lang.lo
-fsource-filename=/usr/local/gcc/gcc-20130825/Build/ia64-suse-linux/
libjava/classpath/lib/classes -MT gnu/java/lang.lo -MD -MP -MF
gnu/java/lang.dep
s @gnu/java/lang.list
../../libcommon.a(pretty-print.o): In function
`pretty_printer::~pretty_printer(
)':
/usr/local/gcc/gcc-20130825/Build/gcc/../../gcc/pretty-print.c:789: undefined
re
ference to `operator delete(void*)'
collect2: error: ld returned 1 exit status
make[3]: *** [../../gnatlink] Error 1
make[3]: Leaving directory `/usr/local/gcc/gcc-20130825/Build/gcc/ada/tools'
make[2]: *** [gnattools-native] Error 2
make[2]: Leaving directory `/usr/local/gcc/gcc-20130825/Build/gnattools'
make[1]: *** [all-gnattools] Error 2

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[glisse at gcc dot gnu.org]

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

--- Comment #4 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Daniel Krügler from comment #3)
> IMO it is important to fix at, because otherwise
> it does have the potential to subtly change overload selection (if noexcept
> is used as part of sfinae) and other static introspection tests.

Your interpretation is probably right (I'll let other developers handle it
anyway). Let me just say that I see this change in overload selection as a
*good* thing, not something we have to fight against. Yes, it is subtle. But if
the compiler knows it will elide the copy (assuming it is consistent between
the noexcept detection and the actual code generation) and the copy is the only
operation that may throw, not taking advantage of this information is a fairly
gratuitous code pessimization. Copy elision changes the set of functions
called, it can change the program's behavior in very visible ways, changing
exception specification looks like a rather minor thing to me in this context.
If people rely on exception specification that badly, they should probably
specify them more explicitly (afaik that's the argument that was given against
noexcept(auto)).
>From gcc-bugs-return-428348-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 25 09:02:08 2013
Return-Path: <gcc-bugs-return-428348-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3059 invoked by alias); 25 Aug 2013 09:02:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3016 invoked by uid 48); 25 Aug 2013 09:02:03 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58148] [4.9 Regression] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed
Date: Sun, 25 Aug 2013 09:02:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on short_desc everconfirmed
Message-ID: <bug-58148-4-QvW6vFKJrr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58148-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58148-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg01272.txt.bz2
Content-length: 771

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX148

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-25
            Summary|[C++11] Fails to insert     |[4.9 Regression] Fails to
                   |iterator range into         |insert iterator range into
                   |sequence container with     |sequence container with
                   |-D_GLIBCXX_DEBUG when       |-D_GLIBCXX_DEBUG when
                   |conversion is needed        |conversion is needed
     Ever confirmed|0                           |1

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-09-29
     Ever confirmed|0                           |1

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> ---
In case we need something more for templates, eg:

template<typename T>
struct A {
  A() noexcept {}
  A(const A&) noexcept(false) {}
};

template<typename T>
void a(A<T>) noexcept {}

template<typename T>
void f()
{
  static_assert(!noexcept(a(A<T>{})), ""); // Error
}

void g()
{
  f<int>();
}

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org

--- Comment #6 from Jason Merrill <jason at gcc dot gnu.org> ---
I think this is a question for CWG.  EDG matches G++ on your testcases.

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org <paolo at gcc dot gnu.org> ---
Author: paolo
Date: Thu Oct  2 18:05:55 2014
New Revision: 215813

URL: https://gcc.gnu.org/viewcvs?rev=215813&root=gcc&view=rev
Log:
/cp
2014-10-02  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/53025
    * cp-tree.h (struct saved_scope): Add noexcept_operand.
    (cp_noexcept_operand): Define.
    * call.c (build_over_call): Use it.
    * parser.c (cp_parser_unary_expression, [RID_NOEXCEPT]): Likewise.
    * pt.c (tsubst_copy_and_build, [NOEXCEPT_EXPR]): Likewise.

/testsuite
2014-10-02  Paolo Carlini  <paolo.carlini@oracle.com>

    PR c++/53025
    * g++.dg/cpp0x/noexcept23.C: New.
    * g++.dg/cpp0x/noexcept24.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/cpp0x/noexcept23.C
    trunk/gcc/testsuite/g++.dg/cpp0x/noexcept24.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/parser.c
    trunk/gcc/cp/pt.c
    trunk/gcc/testsuite/ChangeLog

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> ---
I think we can anyway close this.

[Bug c++/53025] [C++11] noexcept operator depends on copy-elision

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Nathaniel Shead <nshead@gcc.gnu.org>:

https://gcc.gnu.org/g:4719b6f5ae4d758f193a17bbd5fb6cbacd702a23

commit r14-6395-g4719b6f5ae4d758f193a17bbd5fb6cbacd702a23
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Sat Oct 28 16:04:52 2023 +1100

    c++: Fix noexcept checking for trivial operations [PR96090]

    This patch stops eager folding of trivial operations (construction and
    assignment) from occurring when checking for noexceptness. This was
    previously done in PR c++/53025, but only for copy/move construction,
    and the __is_nothrow_xible builtins did not receive the same treatment
    when they were added.

    To handle `is_nothrow_default_constructible`, the patch also ensures
    that when no parameters are passed we do value initialisation instead of
    just building the constructor call: in particular, value-initialisation
    doesn't necessarily actually invoke the constructor for trivial default
    constructors, and so we need to handle this case as well.

    This is contrary to the proposed resolution of CWG2820; for now we just
    ensure it matches the behaviour of the `noexcept` operator and create
    testcases formalising this, and if that issue gets accepted we can
    revisit.

            PR c++/96090
            PR c++/100470

    gcc/cp/ChangeLog:

            * call.cc (build_over_call): Prevent folding of trivial special
            members when checking for noexcept.
            * method.cc (constructible_expr): Perform value-initialisation
            for empty parameter lists.
            (is_nothrow_xible): Treat as noexcept operator.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/noexcept81.C: New test.
            * g++.dg/ext/is_nothrow_constructible7.C: New test.
            * g++.dg/ext/is_nothrow_constructible8.C: New test.

    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>