The constant expression evaluation code was happily replacing an
expression involving a temporary with its constant value even if the
temporary had a destructor that needed to be run.
After fixing that, I needed to adjust expand_default_init to avoid
adding a TARGET_EXPR when we aren't really
On 06/26/2011 10:00 AM, Jason Merrill wrote:
Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, should this go
into 4.6.1 or .2?
I think it's fine to wait for .2, since a class with a non-trivial
destructor is likely to also have a non-trivial, non-constexpr
constructor, which would preven
On Sun, Jun 26, 2011 at 9:00 AM, Jason Merrill wrote:
> The constant expression evaluation code was happily replacing an expression
> involving a temporary with its constant value even if the temporary had a
> destructor that needed to be run.
I thought we wanted literal types to have trivial des
No, that's still the case, just getting confused by the need to also support
constant initialization of non-literal types.
Gabriel Dos Reis wrote:
On Sun, Jun 26, 2011 at 9:00 AM, Jason Merrill wrote:
> The constant expression evaluation code was happily replacing an expression
> involving a t
On Sun, Jun 26, 2011 at 10:13:23AM -0400, Jason Merrill wrote:
> On 06/26/2011 10:00 AM, Jason Merrill wrote:
> >Tested x86_64-pc-linux-gnu, applying to trunk. Jakub, should this go
> >into 4.6.1 or .2?
>
> I think it's fine to wait for .2, since a class with a non-trivial
> destructor is likely t
On Sun, Jun 26, 2011 at 12:09 PM, Jason Merrill wrote:
> No, that's still the case, just getting confused by the need to also support
> constant initialization of non-literal types.
Ah, thanks!
-- Gaby
But yes, I think checking for literal type is a better idea.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 81e093c1d6f2657c8c3c2abc2af559111ca82da4
Author: Jason Merrill
Date: Sun Jun 26 15:23:00 2011 -0400
PR c++/49528
* semantics.c (potential_constant_expression_1): Check
