From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Jeff Law <jeffreyalaw@gmail.com>,
Alexandre Oliva <oliva@adacore.com>,
gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] opts: Disable -gstatement-frontiers by default [PR103788]
Date: Wed, 20 Apr 2022 20:53:57 +0200 [thread overview]
Message-ID: <2AADF633-FAD3-40A3-9422-E0BC095A2CC9@suse.de> (raw)
In-Reply-To: <YmA/byg8CdYQAG6u@tucnak>
> Am 20.04.2022 um 19:15 schrieb Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org>:
>
> 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?
OK.
Richard.
> 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
>
prev parent reply other threads:[~2022-04-20 18:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 17:14 Jakub Jelinek
2022-04-20 18:53 ` Richard Biener [this message]
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=2AADF633-FAD3-40A3-9422-E0BC095A2CC9@suse.de \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=jeffreyalaw@gmail.com \
--cc=oliva@adacore.com \
/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).