public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [C++ Patch] PR 58102 aka DR 1405
@ 2014-09-01 13:48 Paolo Carlini
  2014-09-02 14:11 ` Jason Merrill
  0 siblings, 1 reply; 9+ messages in thread
From: Paolo Carlini @ 2014-09-01 13:48 UTC (permalink / raw)
  To: gcc-patches; +Cc: Jason Merrill

[-- Attachment #1: Type: text/plain, Size: 153 bytes --]

Hi,

I think that in order to implement the resolution we simply have to 
remove the check. Tested x86_64-linux.

Thanks,
Paolo.

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

[-- Attachment #2: CL_58102 --]
[-- Type: text/plain, Size: 351 bytes --]

/cp
2014-09-01  Paolo Carlini  <paolo.carlini@oracle.com>

	DR 1405
	PR c++/58102
	* semantics.c (cxx_eval_outermost_constant_expr): Do not check
	for mutable sub-objects.

/testsuite
2014-09-01  Paolo Carlini  <paolo.carlini@oracle.com>

	DR 1405
	PR c++/58102
	* g++.dg/cpp0x/constexpr-mutable2.C: New.
	* g++.dg/cpp0x/constexpr-mutable1.C: Adjust.

[-- Attachment #3: patch_58102 --]
[-- Type: text/plain, Size: 1839 bytes --]

Index: cp/semantics.c
===================================================================
--- cp/semantics.c	(revision 214779)
+++ cp/semantics.c	(working copy)
@@ -9858,18 +9858,6 @@ cxx_eval_outermost_constant_expr (tree t, bool all
 
   verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);
 
-  if (TREE_CODE (t) != CONSTRUCTOR
-      && cp_has_mutable_p (TREE_TYPE (t)))
-    {
-      /* We allow a mutable type if the original expression was a
-	 CONSTRUCTOR so that we can do aggregate initialization of
-	 constexpr variables.  */
-      if (!allow_non_constant)
-	error ("%qT cannot be the type of a complete constant expression "
-	       "because it has mutable sub-objects", TREE_TYPE (t));
-      non_constant_p = true;
-    }
-
   /* Technically we should check this for all subexpressions, but that
      runs into problems with our internal representation of pointer
      subtraction and the 5.19 rules are still in flux.  */
Index: testsuite/g++.dg/cpp0x/constexpr-mutable1.C
===================================================================
--- testsuite/g++.dg/cpp0x/constexpr-mutable1.C	(revision 214785)
+++ testsuite/g++.dg/cpp0x/constexpr-mutable1.C	(working copy)
@@ -7,6 +7,6 @@ struct A
 };
 
 constexpr A a = { 0, 1 };
-constexpr A b = a;		// { dg-error "mutable" }
+constexpr A b = a;
 constexpr int i = a.i;
 constexpr int j = a.j;		// { dg-error "mutable" }
Index: testsuite/g++.dg/cpp0x/constexpr-mutable2.C
===================================================================
--- testsuite/g++.dg/cpp0x/constexpr-mutable2.C	(revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-mutable2.C	(working copy)
@@ -0,0 +1,10 @@
+// DR 1405, PR c++/58102
+// { dg-do compile { target c++11 } }
+
+struct S {
+  mutable int n;
+  constexpr S() : n() {}
+};
+
+constexpr S s1 {};
+constexpr S s2 = {};

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-01 13:48 [C++ Patch] PR 58102 aka DR 1405 Paolo Carlini
@ 2014-09-02 14:11 ` Jason Merrill
  2014-09-02 14:17   ` Paolo Carlini
  0 siblings, 1 reply; 9+ messages in thread
From: Jason Merrill @ 2014-09-02 14:11 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches

On 09/01/2014 09:47 AM, Paolo Carlini wrote:
> -constexpr A b = a;		// { dg-error "mutable" }
> +constexpr A b = a;

This is wrong; we still need to get an error here.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 14:11 ` Jason Merrill
@ 2014-09-02 14:17   ` Paolo Carlini
  2014-09-02 14:28     ` Jason Merrill
  0 siblings, 1 reply; 9+ messages in thread
From: Paolo Carlini @ 2014-09-02 14:17 UTC (permalink / raw)
  To: Jason Merrill, gcc-patches

Hi,

On 09/02/2014 04:11 PM, Jason Merrill wrote:
> On 09/01/2014 09:47 AM, Paolo Carlini wrote:
>> -constexpr A b = a;        // { dg-error "mutable" }
>> +constexpr A b = a;
>
> This is wrong; we still need to get an error here.
Hum, interesting. Neither current EDG nor current clang error out there. 
Let's see if I can tease the case out...

Thanks,
Paolo.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 14:17   ` Paolo Carlini
@ 2014-09-02 14:28     ` Jason Merrill
  2014-09-02 14:31       ` Paolo Carlini
  2014-09-02 15:07       ` Paolo Carlini
  0 siblings, 2 replies; 9+ messages in thread
From: Jason Merrill @ 2014-09-02 14:28 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches

On 09/02/2014 10:17 AM, Paolo Carlini wrote:
> Let's see if I can tease the case out...

I think you need to leave that hunk alone, and instead fix the new 
testcase by treating = {} more like {}, just as we already don't require 
a copy constructor call for copy-list-initialization.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 14:28     ` Jason Merrill
@ 2014-09-02 14:31       ` Paolo Carlini
  2014-09-02 15:07       ` Paolo Carlini
  1 sibling, 0 replies; 9+ messages in thread
From: Paolo Carlini @ 2014-09-02 14:31 UTC (permalink / raw)
  To: Jason Merrill, gcc-patches

Hi,

On 09/02/2014 04:28 PM, Jason Merrill wrote:
> On 09/02/2014 10:17 AM, Paolo Carlini wrote:
>> Let's see if I can tease the case out...
>
> I think you need to leave that hunk alone, and instead fix the new 
> testcase by treating = {} more like {}, just as we already don't 
> require a copy constructor call for copy-list-initialization.
I see. Thanks a lot for the tip!

Paolo.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 14:28     ` Jason Merrill
  2014-09-02 14:31       ` Paolo Carlini
@ 2014-09-02 15:07       ` Paolo Carlini
  2014-09-02 15:45         ` Jason Merrill
  1 sibling, 1 reply; 9+ messages in thread
From: Paolo Carlini @ 2014-09-02 15:07 UTC (permalink / raw)
  To: Jason Merrill, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

Hi again,

On 09/02/2014 04:28 PM, Jason Merrill wrote:
> On 09/02/2014 10:17 AM, Paolo Carlini wrote:
>> Let's see if I can tease the case out...
>
> I think you need to leave that hunk alone, and instead fix the new 
> testcase by treating = {} more like {}, just as we already don't 
> require a copy constructor call for copy-list-initialization.
By the way, now I really understand the DR (the wording in the 
resolution clarifies what we are *already* doing correctly!).

Anyway, what about the below? Certainly works for the tests which we 
have got.

Thanks,
Paolo.

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


[-- Attachment #2: patch_58102_2 --]
[-- Type: text/plain, Size: 1369 bytes --]

Index: cp/semantics.c
===================================================================
--- cp/semantics.c	(revision 214808)
+++ cp/semantics.c	(working copy)
@@ -9859,11 +9859,14 @@ cxx_eval_outermost_constant_expr (tree t, bool all
   verify_constant (r, allow_non_constant, &non_constant_p, &overflow_p);
 
   if (TREE_CODE (t) != CONSTRUCTOR
+      && (TREE_CODE (t) != TARGET_EXPR
+	  || TREE_CODE (TARGET_EXPR_INITIAL (t)) != AGGR_INIT_EXPR)
       && cp_has_mutable_p (TREE_TYPE (t)))
     {
       /* We allow a mutable type if the original expression was a
 	 CONSTRUCTOR so that we can do aggregate initialization of
-	 constexpr variables.  */
+	 constexpr variables.  Likewise for TARGET_EXPRs with an
+	 AGGR_INIT_EXPR as TARGET_EXPR_INITIAL (c++/58102).  */
       if (!allow_non_constant)
 	error ("%qT cannot be the type of a complete constant expression "
 	       "because it has mutable sub-objects", TREE_TYPE (t));
Index: testsuite/g++.dg/cpp0x/constexpr-mutable2.C
===================================================================
--- testsuite/g++.dg/cpp0x/constexpr-mutable2.C	(revision 0)
+++ testsuite/g++.dg/cpp0x/constexpr-mutable2.C	(working copy)
@@ -0,0 +1,10 @@
+// DR 1405, PR c++/58102
+// { dg-do compile { target c++11 } }
+
+struct S {
+  mutable int n;
+  constexpr S() : n() {}
+};
+
+constexpr S s1 {};
+constexpr S s2 = {};

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 15:07       ` Paolo Carlini
@ 2014-09-02 15:45         ` Jason Merrill
  2014-09-03 10:53           ` Paolo Carlini
  0 siblings, 1 reply; 9+ messages in thread
From: Jason Merrill @ 2014-09-02 15:45 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches

On 09/02/2014 11:07 AM, Paolo Carlini wrote:
> Anyway, what about the below? Certainly works for the tests which we
> have got.

Hmm.  This is definitely an improvement, as it allows a subset of

a non-volatile glvalue of literal type that refers to a non-volatile 
object whose lifetime began within the evalution of e

But it doesn't cover all of that, and in any case we shouldn't need to 
explicitly handle that just for types with mutable subobjects.

I think perhaps it would be better to remove that hunk as in your 
initial patch and replace it with a check in constant_value_1 and an 
explanation in non_const_var_error.

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-02 15:45         ` Jason Merrill
@ 2014-09-03 10:53           ` Paolo Carlini
  2014-09-03 20:33             ` Jason Merrill
  0 siblings, 1 reply; 9+ messages in thread
From: Paolo Carlini @ 2014-09-03 10:53 UTC (permalink / raw)
  To: Jason Merrill, gcc-patches

Hi,

On 09/02/2014 05:45 PM, Jason Merrill wrote:
> On 09/02/2014 11:07 AM, Paolo Carlini wrote:
>> Anyway, what about the below? Certainly works for the tests which we
>> have got.
>
> Hmm.  This is definitely an improvement, as it allows a subset of
>
> a non-volatile glvalue of literal type that refers to a non-volatile 
> object whose lifetime began within the evalution of e
>
> But it doesn't cover all of that, and in any case we shouldn't need to 
> explicitly handle that just for types with mutable subobjects.
>
> I think perhaps it would be better to remove that hunk as in your 
> initial patch and replace it with a check in constant_value_1 and an 
> explanation in non_const_var_error.
In practice, I'm encountering a rather serious problem with moving away 
the check, I'm looking more into it, but maybe I can already explain it 
to you...

The issue, AFAICS, boils down to the difference itself between 
cxx_eval_outermost_constant_expr and cxx_eval_constant_expression: 
changing constant_value_1 means that in principle all the calls of the 
latter (for VAR_DECLs) are impacted. Thus, for example, for the call at 
the beginning of cxx_eval_component_reference:

struct A
{
   int i;
   mutable int j;
};

constexpr A a = { 0, 1 };
constexpr int i = a.i;

how do we avoid emitting a wrong error for the a of a.i?

Paolo.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [C++ Patch] PR 58102 aka DR 1405
  2014-09-03 10:53           ` Paolo Carlini
@ 2014-09-03 20:33             ` Jason Merrill
  0 siblings, 0 replies; 9+ messages in thread
From: Jason Merrill @ 2014-09-03 20:33 UTC (permalink / raw)
  To: Paolo Carlini, gcc-patches

On 09/03/2014 06:53 AM, Paolo Carlini wrote:
> The issue, AFAICS, boils down to the difference itself between
> cxx_eval_outermost_constant_expr and cxx_eval_constant_expression:
> changing constant_value_1 means that in principle all the calls of the
> latter (for VAR_DECLs) are impacted.

Oh, right.

> Thus, for example, for the call at
> the beginning of cxx_eval_component_reference:
>
> struct A
> {
>    int i;
>    mutable int j;
> };
>
> constexpr A a = { 0, 1 };
> constexpr int i = a.i;
>
> how do we avoid emitting a wrong error for the a of a.i?

Perhaps when we get the value of a we replace the mutable initializer 
with a magic "mutable" value and then make sure what we return from 
_outermost_ doesn't contain it?

Jason

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-09-03 20:33 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-01 13:48 [C++ Patch] PR 58102 aka DR 1405 Paolo Carlini
2014-09-02 14:11 ` Jason Merrill
2014-09-02 14:17   ` Paolo Carlini
2014-09-02 14:28     ` Jason Merrill
2014-09-02 14:31       ` Paolo Carlini
2014-09-02 15:07       ` Paolo Carlini
2014-09-02 15:45         ` Jason Merrill
2014-09-03 10:53           ` Paolo Carlini
2014-09-03 20:33             ` Jason Merrill

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).