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 <ja...@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
