This is the mail archive of the
mailing list for the GCC project.
Re: [C++ Patch/RFC] PR 53025
- From: Jason Merrill <jason at redhat dot com>
- To: Paolo Carlini <paolo dot carlini at oracle dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 01 Oct 2014 23:22:45 -0400
- Subject: Re: [C++ Patch/RFC] PR 53025
- Authentication-results: sourceware.org; auth=none
- References: <542C2C69 dot 9000905 at oracle dot com>
On 10/01/2014 12:31 PM, Paolo Carlini wrote:
in this issue Daniel argued that the value of a noexcept expression
should not depend on constructor elision.
I'm open to that, but I don't think it's at all clear in the standard.
Then, in the audit trail Marc
tentatively suggested something like the parser.c hunk below, which just
disables our -felide-constructors optimization when parsing the noexcept
expression. Over the last couple of days, I had a look, noticed that in
any case we still have to handle templates, thus the pt.c hunk, and also
that maybe we can avoid completely disabling -felide-constructors in
noexcept expressions when we know for sure that the constructor at issue
doen't throw: for that in call.s I'm further abusing the
flag_elide_constructors global, in terms of using a special value of 2
when flag_elide_constructor is found == 1 when handling the expression.
The below passes testing, anyway.
Why do we want to avoid completely disabling -felide-constructors, since
it's an unevaluated context anyway?
If you're going to mess with this flag you need to save/restore it in
push/pop_to_top_level as well.