Re: [C++ Patch/RFC] PR 53025

[Paolo Carlini <paolo dot carlini at oracle dot com>]

Hi,

On 10/02/2014 05:22 AM, Jason Merrill wrote:
> 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.
Ok. Personally, I find the analysis in the audit trail rather 
convincing. In practice, clang++ definitely agrees, likewise 
SolarisStudio. Current EDG seems inconsistent, the templated and 
non-templated cases are handled differently.
> > 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?
Agreed.
> If you're going to mess with this flag you need to save/restore it in 
> push/pop_to_top_level as well.
I see. But then if we have to do take care of that I find much more 
clean to just add a global?!? In any case, if I understand correctly the 
logic at the end of push_to_top_level, it would be tricky to reset the 
flag to a sensible value (by default would be 1, but the user may have 
passed -fno-elide-constructors on the command line).

The below passes testing.

Thanks!
Paolo.

////////////////////////

Attachment: patch_53025_2
Description: Text document