Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757808AbcCCOTT (ORCPT ); Thu, 3 Mar 2016 09:19:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55706 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756788AbcCCOTR (ORCPT ); Thu, 3 Mar 2016 09:19:17 -0500 Date: Thu, 3 Mar 2016 15:19:07 +0100 From: Jakub Jelinek To: Ingo Molnar Cc: Arnaldo Carvalho de Melo , Peter Zijlstra , Colin King , Ingo Molnar , linux-kernel@vger.kernel.org, Richard Henderson , Dan Carpenter , Linus Torvalds , Andrew Morton Subject: Re: Q: why didn't GCC warn about this uninitialized variable? (was: Re: [PATCH] perf tests: initialize sa.sa_flags) Message-ID: <20160303141907.GG3017@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1456923322-29697-1-git-send-email-colin.king@canonical.com> <20160302125901.GF6356@twins.programming.kicks-ass.net> <20160302130350.GO3604@kernel.org> <20160302132127.GG6356@twins.programming.kicks-ass.net> <20160302132323.GP3604@kernel.org> <20160303121944.GB2484@gmail.com> <20160303125542.GD3017@tucnak.redhat.com> <20160303132433.GA9460@gmail.com> <20160303134716.GA9860@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160303134716.GA9860@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2542 Lines: 43 On Thu, Mar 03, 2016 at 02:47:16PM +0100, Ingo Molnar wrote: > I tried to distill a testcase out of it, and the following silly hack seems to > trigger it: ... This is a known issue, which we don't have a solution for yet. The thing is, GCC has 2 uninitialized warning passes, one is done very early, on fairly unoptimized code, which warns for -O and above only about must be uninitialized cases in code that is executed unconditionally (if the containing function is executed, and doesn't have PHI handling code), and then a very late uninitialized pass, that warns also about maybe-uninitialized cases, has predicate aware handling in it, etc.; but this warns only about the cases where the uninitialized uses survived through the optimizations until that phase. In the testcase, the conditional uninitialized uses got optimized away, passes seeing that you can get alt_idx initialized say to 2 from one branch and uninitialized from another one just optimize it into 2. Warning right away at that spot when the optimization pass performs this might not be the right thing, as it could warn for stuff in dead code, or couldn't be backed up by the predicate aware uninit analysis which is costly and couldn't be done in every pass that just happens to optimize away some uninitialized stuff. Not to mention that it doesn't have to be always even so obvious to the optimizing pass. Say, when computing value ranges, the uninitialized uses should be ignored, because they can't be used in valid paths, so if say you have value range [2, 34] from one branch and uninitialized use from another branch, the resulting value range will be [2, 34]. Then later on, you just optimize based on this value range and perhaps the uninitialized use will go away because of that. We could handle the uninitialized uses pessimistically, by not optimizing PHI into just initialized_2, etc., by considering uninitialized uses as VARYING ([min, max] range) rather than something that doesn't happen, etc., and then the late uninitialized pass would warn here. But then we'd trade the warning for less optimized code. GCC is primarily an optimizing compiler, rather than static analyzer, so that is why GCC chooses to do what it does. Do you want us introduce -Ow mode, which will prefer warnings over generated code quality? BTW, as for false positives and new warnings, my experience is that in the kernel generally such warnings are just disabled, even if they helped discover severe errors in other packages. Jakub