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