public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@gnu.org>
To: Jason Merrill <jason@redhat.com>
Cc: Christophe Lyon <christophe.lyon@linaro.org>,
	       gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [C++ Patch] [PR c++/88146] do not crash synthesizing inherited ctor(...)
Date: Thu, 17 Jan 2019 04:12:00 -0000	[thread overview]
Message-ID: <oref9bgbxu.fsf@lxoliva.fsfla.org> (raw)
In-Reply-To: <d8f9055b-bcbb-c67c-271c-7b1dcf542ce5@redhat.com> (Jason	Merrill's message of "Fri, 4 Jan 2019 13:55:49 -0500")

On Jan  4, 2019, Jason Merrill <jason@redhat.com> wrote:

> if (tree fn = cp_get_callee_fndecl_nofold (expr))
>   if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))

> ?  The other patch is OK with that change.

Thanks, I've regstrapped this on x86_64- and i686-linux-gnu, and I'm
checking it in momentarily.


[PR88146] avoid diagnostics diffs if cdtor_returns_this

Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms.  Specifically, on ARM, the diagnostics within the subtest
derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did
not match those displayed on other platforms, and the test failed.

The difference seemed to have to do with locations assigned to ctors,
but it was more subtle: on ARM, the instantiation of bor's template
ctor was nested within the instantiation of bar's template ctor
inherited from bor.  The reason turned out to be related with the
internal return type of ctors: arm_cxx_cdtor_returns_this is enabled
for because of AAPCS, while cxx.cdtor_returns_this is disabled on most
other platforms.  While convert_to_void returns early with a VOID
expr, the non-VOID return type of the base ctor CALL_EXPR causes
convert_to_void to inspect the called decl for nodiscard attributes:
maybe_warn_nodiscard -> cp_get_fndecl_from_callee ->
maybe_constant_init -> cxx_eval_outermost_constant_expr ->
instantiate_constexpr_fns -> nested instantiation.

The internal return type assigned to a cdtor should not affect
instantiation (constexpr or template) decisions, IMHO.  We know it
affects diagnostics, but I have a hunch this might bring deeper issues
with it, so I've arranged for the CALL_EXPR handler in convert_to_void
to disregard cdtors, regardless of the ABI.


for  gcc/cp/ChangeLog

	PR c++/88146
	* cvt.c (convert_to_void): Handle all cdtor calls as if
	returning void.
---
 gcc/cp/cvt.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c
index 914281193980..82a44f353c76 100644
--- a/gcc/cp/cvt.c
+++ b/gcc/cp/cvt.c
@@ -1175,6 +1175,16 @@ convert_to_void (tree expr, impl_conv_void implicit, tsubst_flags_t complain)
       break;
 
     case CALL_EXPR:   /* We have a special meaning for volatile void fn().  */
+      /* cdtors may return this or void, depending on
+	 targetm.cxx.cdtor_returns_this, but this shouldn't affect our
+	 decisions here: neither nodiscard warnings (nodiscard cdtors
+	 are nonsensical), nor should any constexpr or template
+	 instantiations be affected by an ABI property that is, or at
+	 least ought to be transparent to the language.  */
+      if (tree fn = cp_get_callee_fndecl_nofold (expr))
+	if (DECL_CONSTRUCTOR_P (fn) || DECL_DESTRUCTOR_P (fn))
+	  return expr;
+
       maybe_warn_nodiscard (expr, implicit);
       break;
 


-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

  reply	other threads:[~2019-01-17  4:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-07  0:23 Alexandre Oliva
2018-12-14 20:14 ` Alexandre Oliva
2018-12-14 20:42 ` Jason Merrill
2018-12-14 21:41   ` Jason Merrill
2018-12-14 22:34     ` Alexandre Oliva
2018-12-14 22:44       ` Jason Merrill
2018-12-14 23:05         ` Alexandre Oliva
2018-12-15 22:11           ` Jason Merrill
2018-12-19 14:36             ` Christophe Lyon
2018-12-19 18:49               ` Alexandre Oliva
2018-12-19 18:52                 ` Jakub Jelinek
2018-12-20  0:04               ` Alexandre Oliva
2018-12-20 16:00                 ` Christophe Lyon
2018-12-20 16:18                 ` Jason Merrill
2018-12-28 22:53                   ` Alexandre Oliva
2018-12-29  6:40                     ` Alexandre Oliva
2018-12-29 13:33                       ` Jakub Jelinek
2019-01-04 18:55                       ` Jason Merrill
2019-01-17  4:12                         ` Alexandre Oliva [this message]
2018-12-29 10:28                     ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=oref9bgbxu.fsf@lxoliva.fsfla.org \
    --to=oliva@gnu.org \
    --cc=christophe.lyon@linaro.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).