From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] cfgexpand: Yet another spot with debug insns references to global vars without varpool nodes [PR105630]
Date: Thu, 19 May 2022 10:12:26 +0200 [thread overview]
Message-ID: <YoX76sLl7pRg88S2@tucnak> (raw)
Hi!
This is similar to the earlier patch to avoid having MEM_EXPRs
referencing global vars without varpool nodes, but this time
the difference is that during gimplification some hashing
actually created DECL_RTLs for the n VAR_DECL and the previous
change was in the if above this when DECL_RTL is NULL and we are
considering creating it.
The following patch drops on the floor references to vars where
we've optimized away the varpool node even when it has DECL_RTL.
Bootstrapped/regtested on x86_64-linux and i686-linux, plus
bootstrapped on those without the cfgexpand.cc change, reapplied
it and rebuilt stage3 cc1/cc1plus, the resulting cc1/cc1plus
binaries on both targets were identical except for the 16-byte
executable_checksum (I've done the second bootstraps in the same
directory as the first one after moving the previous one elsewhere,
so pathnames were the same, just checksum hasn't been regenerated).
So, at least on those binaries this patch doesn't affect debug info
at all.
Ok for trunk?
2022-05-19 Jakub Jelinek <jakub@redhat.com>
PR debug/105630
* cfgexpand.cc (expand_debug_expr): For VAR_DECL, punt for
global vars without symtab node even when they have DECL_RTL
set.
* gcc.dg/pr105630.c: New test.
--- gcc/cfgexpand.cc.jj 2022-05-09 09:09:20.005477502 +0200
+++ gcc/cfgexpand.cc 2022-05-18 13:53:49.622983222 +0200
@@ -4575,6 +4575,10 @@ expand_debug_expr (tree exp)
|| SYMBOL_REF_DECL (XEXP (op0, 0)) != exp)
return NULL;
}
+ else if (VAR_P (exp)
+ && is_global_var (exp)
+ && symtab_node::get (exp) == NULL)
+ return NULL;
else
op0 = copy_rtx (op0);
--- gcc/testsuite/gcc.dg/pr105630.c.jj 2022-05-18 14:02:18.426050242 +0200
+++ gcc/testsuite/gcc.dg/pr105630.c 2022-05-18 14:02:07.103204525 +0200
@@ -0,0 +1,22 @@
+/* PR debug/105630 */
+/* { dg-do compile { target pthread } } */
+/* { dg-options "-O1 -ftree-parallelize-loops=2 -fcompare-debug" } */
+
+int m;
+static int n;
+
+void
+foo (void)
+{
+ int *arr[] = { &n, &n, &n };
+ int unused = n;
+
+ m = 0;
+}
+
+void
+bar (int *arr, int i)
+{
+ while (i < 1)
+ arr[i++] = 1;
+}
Jakub
next reply other threads:[~2022-05-19 8:12 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-19 8:12 Jakub Jelinek [this message]
2022-05-19 9:47 ` Richard Biener
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=YoX76sLl7pRg88S2@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).