public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@adacore.com>
To: gcc-patches@gcc.gnu.org
Cc: jason@redhat.com, nathan@acm.org
Subject: set loc on call even if result is discarded
Date: Wed, 06 Apr 2022 16:37:32 -0300	[thread overview]
Message-ID: <ory20ivw8z.fsf@lxoliva.fsfla.org> (raw)


This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.

The problem was visible in g++.dg/cpp2a/constexpr-dtor3.C: while the
dtor call in the cleanup for f4 was expected at the closing brace, on
returning-this targets it came up at the assignment.

The reason is convoluted: statements in cleanups have their location
information removed, to avoid bumpy debugger behavior, and then set to
the location of the end of the scope.

The cleanup dtor call has its locus cleared in both kinds of targets,
but the end-of-scope locus doesn't make it on returning-this targets.
The calls are wrapped with a cast-to-void to discard the unused return
value, and the existing logic only attached the locus to the
conversion NOP_EXPR.

The call thus remains locus-less.  When constexpr logic copies and
evals the body, it sets unset locations; while copying cleanups, the
locus is taken from the cleanup expression, rather than matching the
end-of-scope locus set by the parser.  So we end up with different
locations.

This patch sets the locus of the call even when it's wrapped by a
convert-to-void NOP_EXPR, so it won't diverge any more.

Regstrapped on x86_64-linux-gnu, also verified the testcase fix on
arm-eabi.  Ok to install?


for  gcc/ChangeLog

	* tree.cc (protected_set_expr_location): Propagate locus to
	call wrapped in cast-to-void.
---
 gcc/tree.cc |   13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gcc/tree.cc b/gcc/tree.cc
index ec200e9a7eb43..228d279ab0aa1 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -5372,7 +5372,18 @@ void
 protected_set_expr_location (tree t, location_t loc)
 {
   if (CAN_HAVE_LOCATION_P (t))
-    SET_EXPR_LOCATION (t, loc);
+    {
+      SET_EXPR_LOCATION (t, loc);
+      /* Avoid locus differences for C++ cdtor calls depending on whether
+	 cdtor_returns_this: a conversion to void is added to discard the return
+	 value, and this conversion ends up carrying the location, and when it
+	 gets discarded, the location is lost.  So hold it in the call as
+	 well.  */
+      if (TREE_CODE (t) == NOP_EXPR
+	  && TREE_TYPE (t) == void_type_node
+	  && TREE_CODE (TREE_OPERAND (t, 0)) == CALL_EXPR)
+	SET_EXPR_LOCATION (TREE_OPERAND (t, 0), loc);
+    }
   else if (t && TREE_CODE (t) == STATEMENT_LIST)
     {
       t = expr_single (t);


-- 
Alexandre Oliva, happy hacker                https://FSFLA.org/blogs/lxo/
   Free Software Activist                       GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>

             reply	other threads:[~2022-04-06 19:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-06 19:37 Alexandre Oliva [this message]
2022-04-06 21:19 ` Jason Merrill
2022-04-07 22:48   ` [PATCH] c++: " Alexandre Oliva
2022-04-08  6:42     ` Richard Biener
2022-04-09  3:45     ` Jason Merrill
2022-04-11 15:19       ` [PATCH v2] " 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=ory20ivw8z.fsf@lxoliva.fsfla.org \
    --to=oliva@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    --cc=nathan@acm.org \
    /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).