[PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization

Martin Sebor msebor@gmail.com
Tue Jul 23 16:31:00 GMT 2019


On 7/22/19 10:26 PM, JiangNing OS wrote:
> This patch is to fix PR91195. Is it OK for trunk?
> 
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index 711a31ea597..4db36644160 100644
> --- 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;

The no-warning bit is sometimes (typically?) set by the middle-end
after a warning has been issued, to avoid triggering other warnings
down the line for an already diagnosed expression.  Unless it's
done just for the purposes of a single pass and the bit is cleared
afterwards, using it to avoid potential false positives doesn't
seem like a robust solution.  It will mask warnings for constructs
that have been determined to be invalid.

FWIW, the middle-end is susceptible to quite a few false positives
that would nice to avoid.  We have discussed various approaches to
the problem but setting the no-warning bit seems like too blunt of
an instrument.

Martin



More information about the Gcc-patches mailing list