From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13032 invoked by alias); 22 Aug 2007 16:49:58 -0000 Received: (qmail 11163 invoked by uid 48); 22 Aug 2007 16:49:47 -0000 Date: Wed, 22 Aug 2007 16:49:00 -0000 Message-ID: <20070822164947.11161.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/32759] False claim of that "xyz is used uninitialized" In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "manu at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg01580.txt.bz2 ------- Comment #4 from manu at gcc dot gnu dot org 2007-08-22 16:49 ------- Basically, when we reach "diff = xlimit;" we don't know that xlimit must be initialized. This may end up in different scenarios depending on the SSA tree finally generated. In any of those scenarios, not warning is sheer luck. If you remove the assignment to diff, still when we reach "ang ? xlimit : 0.0;" we don't know that xlimit is always initialized. We get the "may be" because we don't know the value of "ang", so xlimit may not be used at all. Finally, I guess that using constants make the warning disappear because the constant-propagation pass assumes that the uninitialized value of xlimit is either of the constants and thus xlimit is never used uninitialized. My conclusion here is that we should not get a "is uninitialized". Maybe we can use the fact that the block is not entered 100% of times to avoid saying "is used"? Nonetheless, avoiding the warning completely depends on being able to avoid a default case for the switch (which is a missed-optimization in VRP and not a diagnostics problem). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32759