public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/aoliva/heads/testme)] c++: for contracts, cdtors never return this
@ 2023-11-18  5:36 Alexandre Oliva
  0 siblings, 0 replies; 4+ messages in thread
From: Alexandre Oliva @ 2023-11-18  5:36 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:444347c11ba38a114d3a21c271265723418d72dd

commit 444347c11ba38a114d3a21c271265723418d72dd
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Sat Nov 18 02:11:24 2023 -0300

    c++: for contracts, cdtors never return this
    
    When targetm.cxx.cdtor_return_this() holds, cdtors have a
    non-VOID_TYPE_P result, but IMHO this ABI implementation detail
    shouldn't leak to the abstract language conceptual framework, in which
    cdtors don't have return values.  For contracts, specifically those
    that establish postconditions on results, such a leakage is present,
    and the present patch puts an end to it: with it, cdtors get an error
    for result postconditions regardless of the ABI.  This fixes
    g++.dg/contracts/contracts-ctor-dtor2.C on arm-eabi.
    
    
    for  gcc/cp/ChangeLog
    
            * contracts.cc (check_postcondition_result): Cope with
            cdtor_return_this.

Diff:
---
 gcc/cp/contracts.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/contracts.cc b/gcc/cp/contracts.cc
index 66d2298a9bf..035ca4827e7 100644
--- a/gcc/cp/contracts.cc
+++ b/gcc/cp/contracts.cc
@@ -636,7 +636,11 @@ make_postcondition_variable (cp_expr id)
 bool
 check_postcondition_result (tree decl, tree type, location_t loc)
 {
-  if (VOID_TYPE_P (type))
+  /* Do not be confused by targetm.cxx.cdtor_return_this ();
+     conceptually, cdtors have no return value.  */
+  if (VOID_TYPE_P (type)
+      || DECL_CONSTRUCTOR_P (decl)
+      || DECL_DESTRUCTOR_P (decl))
     {
       error_at (loc,
 		DECL_CONSTRUCTOR_P (decl)

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

* [gcc(refs/users/aoliva/heads/testme)] c++: for contracts, cdtors never return this
@ 2023-11-29  4:35 Alexandre Oliva
  0 siblings, 0 replies; 4+ messages in thread
From: Alexandre Oliva @ 2023-11-29  4:35 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:554f30e1af04d885fbd149561c526af572b0cbc4

commit 554f30e1af04d885fbd149561c526af572b0cbc4
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Wed Nov 29 00:54:37 2023 -0300

    c++: for contracts, cdtors never return this
    
    When targetm.cxx.cdtor_return_this() holds, cdtors have a
    non-VOID_TYPE_P result, but IMHO this ABI implementation detail
    shouldn't leak to the abstract language conceptual framework, in which
    cdtors don't have return values.  For contracts, specifically those
    that establish postconditions on results, such a leakage is present,
    and the present patch puts an end to it: with it, cdtors get an error
    for result postconditions regardless of the ABI.  This fixes
    g++.dg/contracts/contracts-ctor-dtor2.C on arm-eabi.
    
    
    for  gcc/cp/ChangeLog
    
            * contracts.cc (check_postcondition_result): Cope with
            cdtor_return_this.

Diff:
---
 gcc/cp/contracts.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/contracts.cc b/gcc/cp/contracts.cc
index 66d2298a9bf..035ca4827e7 100644
--- a/gcc/cp/contracts.cc
+++ b/gcc/cp/contracts.cc
@@ -636,7 +636,11 @@ make_postcondition_variable (cp_expr id)
 bool
 check_postcondition_result (tree decl, tree type, location_t loc)
 {
-  if (VOID_TYPE_P (type))
+  /* Do not be confused by targetm.cxx.cdtor_return_this ();
+     conceptually, cdtors have no return value.  */
+  if (VOID_TYPE_P (type)
+      || DECL_CONSTRUCTOR_P (decl)
+      || DECL_DESTRUCTOR_P (decl))
     {
       error_at (loc,
 		DECL_CONSTRUCTOR_P (decl)

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

* [gcc(refs/users/aoliva/heads/testme)] c++: for contracts, cdtors never return this
@ 2023-11-23 11:46 Alexandre Oliva
  0 siblings, 0 replies; 4+ messages in thread
From: Alexandre Oliva @ 2023-11-23 11:46 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:8c7239e0162b5652998867d74fc39b3a99019681

commit 8c7239e0162b5652998867d74fc39b3a99019681
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Sat Nov 18 02:11:24 2023 -0300

    c++: for contracts, cdtors never return this
    
    When targetm.cxx.cdtor_return_this() holds, cdtors have a
    non-VOID_TYPE_P result, but IMHO this ABI implementation detail
    shouldn't leak to the abstract language conceptual framework, in which
    cdtors don't have return values.  For contracts, specifically those
    that establish postconditions on results, such a leakage is present,
    and the present patch puts an end to it: with it, cdtors get an error
    for result postconditions regardless of the ABI.  This fixes
    g++.dg/contracts/contracts-ctor-dtor2.C on arm-eabi.
    
    
    for  gcc/cp/ChangeLog
    
            * contracts.cc (check_postcondition_result): Cope with
            cdtor_return_this.

Diff:
---
 gcc/cp/contracts.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/contracts.cc b/gcc/cp/contracts.cc
index 66d2298a9bf..035ca4827e7 100644
--- a/gcc/cp/contracts.cc
+++ b/gcc/cp/contracts.cc
@@ -636,7 +636,11 @@ make_postcondition_variable (cp_expr id)
 bool
 check_postcondition_result (tree decl, tree type, location_t loc)
 {
-  if (VOID_TYPE_P (type))
+  /* Do not be confused by targetm.cxx.cdtor_return_this ();
+     conceptually, cdtors have no return value.  */
+  if (VOID_TYPE_P (type)
+      || DECL_CONSTRUCTOR_P (decl)
+      || DECL_DESTRUCTOR_P (decl))
     {
       error_at (loc,
 		DECL_CONSTRUCTOR_P (decl)

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

* [gcc(refs/users/aoliva/heads/testme)] c++: for contracts, cdtors never return this
@ 2023-11-19  4:44 Alexandre Oliva
  0 siblings, 0 replies; 4+ messages in thread
From: Alexandre Oliva @ 2023-11-19  4:44 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:a7eceed38cf99e793da0395180f564999cf96f21

commit a7eceed38cf99e793da0395180f564999cf96f21
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Sat Nov 18 02:11:24 2023 -0300

    c++: for contracts, cdtors never return this
    
    When targetm.cxx.cdtor_return_this() holds, cdtors have a
    non-VOID_TYPE_P result, but IMHO this ABI implementation detail
    shouldn't leak to the abstract language conceptual framework, in which
    cdtors don't have return values.  For contracts, specifically those
    that establish postconditions on results, such a leakage is present,
    and the present patch puts an end to it: with it, cdtors get an error
    for result postconditions regardless of the ABI.  This fixes
    g++.dg/contracts/contracts-ctor-dtor2.C on arm-eabi.
    
    
    for  gcc/cp/ChangeLog
    
            * contracts.cc (check_postcondition_result): Cope with
            cdtor_return_this.

Diff:
---
 gcc/cp/contracts.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/contracts.cc b/gcc/cp/contracts.cc
index 66d2298a9bf..035ca4827e7 100644
--- a/gcc/cp/contracts.cc
+++ b/gcc/cp/contracts.cc
@@ -636,7 +636,11 @@ make_postcondition_variable (cp_expr id)
 bool
 check_postcondition_result (tree decl, tree type, location_t loc)
 {
-  if (VOID_TYPE_P (type))
+  /* Do not be confused by targetm.cxx.cdtor_return_this ();
+     conceptually, cdtors have no return value.  */
+  if (VOID_TYPE_P (type)
+      || DECL_CONSTRUCTOR_P (decl)
+      || DECL_DESTRUCTOR_P (decl))
     {
       error_at (loc,
 		DECL_CONSTRUCTOR_P (decl)

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

end of thread, other threads:[~2023-11-29  4:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-18  5:36 [gcc(refs/users/aoliva/heads/testme)] c++: for contracts, cdtors never return this Alexandre Oliva
2023-11-19  4:44 Alexandre Oliva
2023-11-23 11:46 Alexandre Oliva
2023-11-29  4:35 Alexandre Oliva

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).