public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: JiangNing OS <jiangning@os.amperecomputing.com>,
	Jeff Law <law@redhat.com>,        Martin Sebor <msebor@gmail.com>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization
Date: Mon, 29 Jul 2019 16:03:00 -0000	[thread overview]
Message-ID: <20190729155032.GC15878@tucnak> (raw)
In-Reply-To: <MN2PR01MB5424AEF5B753FFAEB6FEB00E9CC70@MN2PR01MB5424.prod.exchangelabs.com>

On Tue, Jul 23, 2019 at 04:26:24AM +0000, JiangNing OS wrote:
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,9 @@
> +2019-07-22  Jiangning Liu  <jiangning.liu@amperecomputing.com>
> +
> +	PR middle-end/91195
> +	* tree-ssa-phiopt.c (cond_store_replacement): Work around
> +	-Wmaybe-uninitialized warning.
> +
>  2019-07-22  Stafford Horne  <shorne@gmail.com>
>  
>  	* config/or1k/or1k.c (or1k_expand_compare): Check for int before
> diff --git a/gcc/tree-ssa-phiopt.c b/gcc/tree-ssa-phiopt.c
> index b64bde695f4..7a86007d087 100644
> --- a/gcc/tree-ssa-phiopt.c
> +++ b/gcc/tree-ssa-phiopt.c
> @@ -2240,6 +2240,14 @@ cond_store_replacement (basic_block middle_bb, basic_block join_bb,
>        tree base = get_base_address (lhs);
>        if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
>  	return false;
> +
> +      /* The transformation below will inherently introduce a memory load,
> +	 for which LHS may not be initialized yet if it is not in NOTRAP,
> +	 so a -Wmaybe-uninitialized warning message could be triggered.
> +	 Since it's a bit hard to have a very accurate uninitialization
> +	 analysis to memory reference, we disable the warning here to avoid
> +	 confusion.  */
> +      TREE_NO_WARNING (lhs) = 1;

I don't like this, but not for the reasons Martin stated, we use
TREE_NO_WARNING not just when we've emitted warnings, but in many places
when we've done something that might trigger false positives.
Yes, it would be nice to do it more selectively.

The problem I see with the above though is that lhs might very well be
a decl, and setting TREE_NO_WARNING on it then doesn't affect only the
hoisted load, but also all other code that refers to the decl.

If the TREE_NO_WARNING bit is set on something that isn't shareable, that is
fine with me, like a MEM_REF, TARGET_MEM_REF or handled component.  If lhs
is a decl, can we force a MEM_REF around it (and won't we fold it back to
the decl?)?  Or perhaps better, can we gimple_set_no_warning on the load
stmt instead?

	Jakub

  parent reply	other threads:[~2019-07-29 15:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23  5:52 JiangNing OS
2019-07-23 16:31 ` Martin Sebor
2019-07-24 15:28   ` Jeff Law
2019-07-24 17:00     ` Martin Sebor
2019-07-24 17:23       ` Jeff Law
2019-07-24 18:09         ` Martin Sebor
2019-07-25  6:27           ` JiangNing OS
2019-07-25 19:09             ` Martin Sebor
2019-07-26  5:07           ` Jeff Law
2019-07-29 16:10           ` Jakub Jelinek
2019-07-30  8:35             ` Richard Biener
2019-07-30  8:36               ` Jakub Jelinek
2019-07-30  8:49                 ` Richard Biener
2019-07-30 14:51                   ` Martin Sebor
2019-08-07 22:17                     ` Jeff Law
2019-09-03 20:22           ` Jeff Law
2019-07-24 16:00 ` Jeff Law
2019-07-29 16:03 ` Jakub Jelinek [this message]
2019-09-03 20:27   ` Jeff Law
2019-11-20  0:14     ` Jakub Jelinek
2019-11-20  2:33       ` Jeff Law

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=20190729155032.GC15878@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jiangning@os.amperecomputing.com \
    --cc=law@redhat.com \
    --cc=msebor@gmail.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).