[C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598)

[C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598)

[Jakub Jelinek]

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

Hi!

The following testcase is rejected, because we determine B as void &
rather than the expected void when -flifetime-dse.

I'd say the main problem is premature folding, that we lower the trivial
destructor already at parsing time, rather than cp_fold, I'd say that goes
against the intentions of the late folding.

That said, these patch attempts to address this differently (in a way that
would also be backportable).

With -fno-lifetime-dse, when the test passes, the trivial destructor is
folded into (void) &instance and lvalue_kind returns clk_none for that, so
finish_decltype_type returns just void for it.

With -flifetime-dse, the trivial destructor is folded into a void mode
MODIFY_EXPR instance = {CLOBBER} and lvalue_kind returns clk_ordinary in
that case, so finish_decltype_type then applies the rules and makes void &
out of it.

The first patch fixes this by forcibly wrapping the MODIFY_EXPR into a void
type NOP_EXPR, so that lvalue_kind still considers it clk_none.

The second patch fixes that by special casing void type MODIFY_EXPR, I
believe if we have void type MODIFY_EXPR, then it can't be an lvalue.

Another option would be to tweak finish_decltype_type to special case
VOID_TYPE_P and never try to create a reference for it (which is not valid
in C++).

Both patches successfully bootstrapped/regtested on x86_64-linux and
i686-linux.

2019-05-24  Jakub Jelinek  <jakub@redhat.com>

	PR c++/90598
	* call.c (build_trivial_dtor_call): Wrap MODIFY_EXPR for
	-flifetime-dse into void_type_node NOP_EXPR.

	* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/call.c.jj	2019-05-23 12:57:16.658493722 +0200
+++ gcc/cp/call.c	2019-05-23 18:37:09.570874611 +0200
@@ -7995,8 +7995,8 @@ build_trivial_dtor_call (tree instance)
 
   /* A trivial destructor should still clobber the object.  */
   tree clobber = build_clobber (TREE_TYPE (instance));
-  return build2 (MODIFY_EXPR, void_type_node,
-		 instance, clobber);
+  return build1 (NOP_EXPR, void_type_node,
+		 build2 (MODIFY_EXPR, void_type_node, instance, clobber));
 }
 
 /* Subroutine of the various build_*_call functions.  Overload resolution
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj	2019-05-23 18:39:37.034464509 +0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C	2019-05-23 18:39:05.471980348 +0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template <typename T> struct C;
+template <> struct C<void> {};
+C<B> t;

	Jakub

[-- Attachment #2: T824a --]
[-- Type: text/plain, Size: 905 bytes --]

2019-05-24  Jakub Jelinek  <jakub@redhat.com>

	PR c++/90598
	* tree.c (lvalue_kind): Return clk_none for MODIFY_EXPR with
	VOID_TYPE_P.

	* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/tree.c.jj	2019-05-20 21:59:19.886720194 +0200
+++ gcc/cp/tree.c	2019-05-23 23:37:42.335181291 +0200
@@ -245,6 +245,10 @@ lvalue_kind (const_tree ref)
       return clk_ordinary;
 
     case MODIFY_EXPR:
+      if (TREE_TYPE (ref) && VOID_TYPE_P (TREE_TYPE (ref)))
+	return clk_none;
+      return clk_ordinary;
+
     case TYPEID_EXPR:
       return clk_ordinary;
 
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj	2019-05-23 18:39:37.034464509 +0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C	2019-05-23 18:39:05.471980348 +0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template <typename T> struct C;
+template <> struct C<void> {};
+C<B> t;

Re: [C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598)

[Jason Merrill]

On 5/24/19 4:21 AM, Jakub Jelinek wrote:
> The second patch fixes that by special casing void type MODIFY_EXPR, I
> believe if we have void type MODIFY_EXPR, then it can't be an lvalue.

Any expression with void type is a prvalue, so let's not limit this to 
MODIFY_EXPR.

Jason

[C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598, take 2)

[Jakub Jelinek]

On Wed, May 29, 2019 at 12:31:52PM -0400, Jason Merrill wrote:
> On 5/24/19 4:21 AM, Jakub Jelinek wrote:
> > The second patch fixes that by special casing void type MODIFY_EXPR, I
> > believe if we have void type MODIFY_EXPR, then it can't be an lvalue.
> 
> Any expression with void type is a prvalue, so let's not limit this to
> MODIFY_EXPR.

So like this?  So far no regressions in make check-c++-all, ok if it
passes full bootstrap/regtest?

The fact that cv void type expressions are prvalues has been clarified
only recently in
https://github.com/cplusplus/draft/commit/27d19661fbb0a5424f72330724d9809618efbb8b
it seems, is it true that they have been prvalues already in C++11 and
non-lvalues in C++98?

2019-05-29  Jakub Jelinek  <jakub@redhat.com>

	PR c++/90598
	* tree.c (lvalue_kind): Return clk_none for expressions with
	with VOID_TYPE_P.

	* g++.dg/cpp0x/pr90598.C: New test.

--- gcc/cp/tree.c.jj	2019-05-20 23:33:13.819084157 +0200
+++ gcc/cp/tree.c	2019-05-29 18:44:35.619408978 +0200
@@ -83,6 +83,10 @@ lvalue_kind (const_tree ref)
   if (ref == current_class_ptr)
     return clk_none;
 
+  /* Expressions with cv void type are prvalues.  */
+  if (TREE_TYPE (ref) && VOID_TYPE_P (TREE_TYPE (ref)))
+    return clk_none;
+
   switch (TREE_CODE (ref))
     {
     case SAVE_EXPR:
--- gcc/testsuite/g++.dg/cpp0x/pr90598.C.jj	2019-05-29 18:41:43.882194503 +0200
+++ gcc/testsuite/g++.dg/cpp0x/pr90598.C	2019-05-29 18:41:43.882194503 +0200
@@ -0,0 +1,8 @@
+// PR c++/90598
+// { dg-do compile { target c++11 } }
+
+struct A {};
+using B = decltype(A ().~A ());
+template <typename T> struct C;
+template <> struct C<void> {};
+C<B> t;


	Jakub

Re: [C++ PATCH] Fix decltype on a trivial dtor with -flifetime-dse (PR c++/90598, take 2)

[Jason Merrill]

On 5/29/19 1:12 PM, Jakub Jelinek wrote:
> On Wed, May 29, 2019 at 12:31:52PM -0400, Jason Merrill wrote:
>> On 5/24/19 4:21 AM, Jakub Jelinek wrote:
>>> The second patch fixes that by special casing void type MODIFY_EXPR, I
>>> believe if we have void type MODIFY_EXPR, then it can't be an lvalue.
>>
>> Any expression with void type is a prvalue, so let's not limit this to
>> MODIFY_EXPR.
> 
> So like this?  So far no regressions in make check-c++-all, ok if it
> passes full bootstrap/regtest?

OK.

> The fact that cv void type expressions are prvalues has been clarified
> only recently in
> https://github.com/cplusplus/draft/commit/27d19661fbb0a5424f72330724d9809618efbb8b
> it seems, is it true that they have been prvalues already in C++11 and
> non-lvalues in C++98?

Even if it wasn't stated clearly, it's never been possible to form an 
lvalue of void type.

Jason