public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>,
	Jeff Law <jeffreyalaw@gmail.com>,
	Alexandre Oliva <oliva@adacore.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] opts: Disable -gstatement-frontiers by default [PR103788]
Date: Wed, 20 Apr 2022 19:14:23 +0200	[thread overview]
Message-ID: <YmA/byg8CdYQAG6u@tucnak> (raw)

Hi!

As mentioned in those PRs and I think in others too, there are some long
time unresolved -fcompare-debug issues with DEBUG_BEGIN_STMTs in the FEs and
during gimplification, especially with statement expressions, where we end
up with different code generation depending on whether there are
DEBUG_BEGIN_STMTs (which force STATEMENT_LISTs) or not (in that case
we often have just the single expression from the list).
I've tried to fix that several times, but nothing worked.
Furthermore, Alex mentioned in bugzilla that there are no consumers of the
statement frontiers right now.

This patch turns -gstatement-frontiers off by default because of those
2 reasons, consumers for those can still be added (one can test with
explicit -gstatement-frontiers) and if/once that happens, perhaps somebody
will have some great idea how to resolve those -fcompare-debug issues.

Until then, can we go with this?

Bootstrapped/regtested on powerpc64le-linux, ok for trunk if it also passes
bootstrap/regtest on x86_64-linux/i686-linux?

2022-04-20  Jakub Jelinek  <jakub@redhat.com>

	PR debug/103788
	PR middle-end/100733
	PR debug/104180
	* opts.cc (finish_options): Disable -gstatement-frontiers by default.

	* gcc.dg/pr103788.c: New test.
	* c-c++-common/ubsan/pr100733.c: New test.
	* g++.dg/debug/pr104180.C: New test.

--- gcc/opts.cc.jj	2022-04-06 17:42:03.084190238 +0200
+++ gcc/opts.cc	2022-04-20 13:12:22.282322920 +0200
@@ -1317,12 +1317,16 @@ finish_options (struct gcc_options *opts
 	debug_info_level = DINFO_LEVEL_NONE;
     }
 
+  /* Don't enable -gstatement-frontiers by default until some consumers
+     actually consume it and until the issues with DEBUG_BEGIN_STMTs
+     affecting code generation e.g. for statement expressions are resolved.
+     See PR103788, PR104180, PR100733.
   if (!OPTION_SET_P (debug_nonbind_markers_p))
     debug_nonbind_markers_p
       = (optimize
 	 && debug_info_level >= DINFO_LEVEL_NORMAL
 	 && dwarf_debuginfo_p ()
-	 && !(flag_selective_scheduling || flag_selective_scheduling2));
+	 && !(flag_selective_scheduling || flag_selective_scheduling2));  */
 
   /* Note -fvar-tracking is enabled automatically with OPT_LEVELS_1_PLUS and
      so we need to drop it if we are called from optimize attribute.  */
--- gcc/testsuite/gcc.dg/pr103788.c.jj	2022-04-20 13:13:47.253141338 +0200
+++ gcc/testsuite/gcc.dg/pr103788.c	2022-04-20 13:13:29.301390970 +0200
@@ -0,0 +1,28 @@
+/* PR debug/103788 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fcompare-debug" } */
+
+int
+bar (void);
+
+int
+foo (int x)
+{
+  int i;
+
+  for (i = 0; i <= __INT_MAX__; ++i)
+    x += bar () < (x ? 2 : 1);
+
+  return x;
+}
+
+int
+baz (int x)
+{
+  int i;
+
+  for (i = 0; i <= __INT_MAX__; ++i)
+    x += bar () < (
+    x ? 2 : 1 );
+  return x;
+}
--- gcc/testsuite/c-c++-common/ubsan/pr100733.c.jj	2022-04-20 13:18:09.135499667 +0200
+++ gcc/testsuite/c-c++-common/ubsan/pr100733.c	2022-04-20 13:18:43.031028328 +0200
@@ -0,0 +1,9 @@
+/* PR middle-end/100733 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fsanitize=undefined -fcompare-debug -fdisable-tree-phiopt2" } */
+
+int
+foo (int x)
+{
+  return (__builtin_expect (({ x != 0; }) ? 0 : 1, 3) == 0) * -1 << 0;
+}
--- gcc/testsuite/g++.dg/debug/pr104180.C.jj	2022-04-20 13:14:51.468248383 +0200
+++ gcc/testsuite/g++.dg/debug/pr104180.C	2022-04-20 13:15:17.856881425 +0200
@@ -0,0 +1,14 @@
+/* PR debug/104180 */
+/* { dg-do compile } */
+/* { dg-options "-O1 -fcompare-debug" } */
+
+int a[5];
+
+void
+foo (void)
+{
+  unsigned int b;
+
+  for (b = 3; ; b--)
+    a[b] = ({ a[b + 1]; });
+}

	Jakub


             reply	other threads:[~2022-04-20 17:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20 17:14 Jakub Jelinek [this message]
2022-04-20 18:53 ` 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=YmA/byg8CdYQAG6u@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jeffreyalaw@gmail.com \
    --cc=oliva@adacore.com \
    --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).