From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rguenther@suse.de>
Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29])
 by sourceware.org (Postfix) with ESMTPS id 342953858D3C
 for <gcc-patches@gcc.gnu.org>; Mon, 22 Aug 2022 06:14:24 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 342953858D3C
Received: from relay2.suse.de (relay2.suse.de [149.44.160.134])
 by smtp-out2.suse.de (Postfix) with ESMTP id A0A5B5C7C7;
 Mon, 22 Aug 2022 06:14:22 +0000 (UTC)
Received: from wotan.suse.de (wotan.suse.de [10.160.0.1])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by relay2.suse.de (Postfix) with ESMTPS id 6DEF72C141;
 Mon, 22 Aug 2022 06:14:22 +0000 (UTC)
Date: Mon, 22 Aug 2022 06:14:22 +0000 (UTC)
From: Richard Biener <rguenther@suse.de>
To: Andrew Pinski <pinskia@gmail.com>
cc: Andreas Schwab <schwab@linux-m68k.org>, juzhe.zhong@rivai.ai, 
 gcc-patches@gcc.gnu.org, kito.cheng@gmail.com, andrew@sifive.com
Subject: Re: [PATCH] RISC-V: Add runtime invariant support
In-Reply-To: <CA+=Sn1nLnyjt+1cJKVH=WnoGx=XcC8evewyzNuzaWjAAYe_+dg@mail.gmail.com>
Message-ID: <nycvar.YFH.7.77.849.2208220609300.13569@jbgna.fhfr.qr>
References: <20220817071950.271762-1-juzhe.zhong@rivai.ai>
 <87h726h7et.fsf@linux-m68k.org>
 <CA+=Sn1nLnyjt+1cJKVH=WnoGx=XcC8evewyzNuzaWjAAYe_+dg@mail.gmail.com>
User-Agent: Alpine 2.22 (LSU 394 2020-01-19)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Aug 2022 06:14:25 -0000

On Sat, 20 Aug 2022, Andrew Pinski wrote:

> On Sat, Aug 20, 2022 at 3:34 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
> >
> > This breaks bootstrap:
> >
> > ../../gcc/tree-vect-loop-manip.cc: In function 'void vect_gen_vector_loop_niters(loop_vec_info, tree, tree_node**, tree_node**, bool)':
> > ../../gcc/tree-vect-loop-manip.cc:1981:26: error: 'const_vf' may be used uninitialized [-Werror=maybe-uninitialized]
> >  1981 |   unsigned HOST_WIDE_INT const_vf;
> >       |                          ^~~~~~~~
> > cc1plus: all warnings being treated as errors
> > make[3]: *** [Makefile:1146: tree-vect-loop-manip.o] Error 1
> > make[2]: *** [Makefile:4977: all-stage2-gcc] Error 2
> > make[1]: *** [Makefile:30363: stage2-bubble] Error 2
> > make: *** [Makefile:1065: all] Error 2
> 
> 
> This looks like a real uninitialized variable issue.
> I even can't tell if the paths that lead to using const_vf will be
> always set so how we expect GCC to do the same.
> The code that uses const_vf was added with r11-5820-cdcbef3c3310,
> CCing the author there.

The key is

  tree log_vf = NULL_TREE;
...
  unsigned HOST_WIDE_INT const_vf;
  if (vf.is_constant (&const_vf)
      && !LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
    {
...
      log_vf = build_int_cst (type, exact_log2 (const_vf));
...
    }
...
      if (stmts != NULL && log_vf)
        {
... use const_vf ...

so it's uninit analysis little mind that is confused.  There is code
that's supposed to handle the situation (setting flag under condition,
testing that flag instead of condition) but maybe it's too twisted
here.  One could refector this as

 bool const_vf_p = vf.is_constant (&const_vf);
 if (const_vf_p
     && ...)
...
   if (stmts != NULL && const_vf_p)
...

and hope uninits mind is good enough to see log_vf is not used
uninitialized.

I can also look into why uninit doesn't get it, but preprocessed
source would be handy then.

Richard.