public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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
> 

      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).