From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-224515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 20990 invoked by alias); 13 Jul 2007 19:32:05 -0000
Received: (qmail 20962 invoked by uid 48); 13 Jul 2007 19:31:55 -0000
Date: Fri, 13 Jul 2007 19:32:00 -0000
Subject: [Bug c/32759]  New: False claim of that "xyz is used uninitialized"
X-Bugzilla-Reason: CC
Message-ID: <bug-32759-12315@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "bernard at brenda-arkle dot demon dot co dot uk" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2007-07/txt/msg01534.txt.bz2

I'd accept "may be used uninitialized", but I'm positively told
"is used uninitialized", which ain't true.

This is similar to bugs 32395 and 22197: apologies if it turns out to be
a mere duplicate.  My code example is much simpler than the examples
given for those bugs: there are no aggregate types, the parameter
passing isn't interesting, and initialisation obviously DOES happen.

Also seen in 4.1.2 (I got around to building 4.2.0 so I could
verify the problem...)


The warning is attached to the line where 'diff' is assigned a
value.  Note that this value is not then used again.

Required flags: -c -Wuninitialized -O1
(n.b.: -Wuninitialized is incompatible with -O0, but any other -O<n> will do)
No headers required.

double Find_Limit(double xcentre, unsigned ang)
{
        double diff;
        long xlimit;

        ang &= 1U;

        switch (ang)
        {
                case 0U:
                        xlimit = xcentre;
                        break;

                case 1U:
                        xlimit = xcentre;
                        break;
        }

        diff = xlimit;

        return ang ? xlimit : 0.0;
} /* End of function Find_Limit() */

Removing the assignment to diff (which isn't used) demotes
"is uninitialized" to "may be uninitialized".  Combining the two
case-clauses of the switch statement under the same header
(case 0U: case 1U: <stuff>) likewise demotes.  Removing the use of
xlimit in the final (returned-value) expression removes the warning
entirely (so it DOES notice that diff isn't used - or is it more
confused than I think?)

If, in the assignments to xlimit, the right-hand expressions are replaced
with literal constants, the warning disappears entirely - even if the
two literal constants are unequal.  So does the compiler recognise
that the two handled cases in the switch are exhaustive or doesn't it?

This looks deeply strange to me.


-- 
           Summary: False claim of that "xyz is used uninitialized"
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bernard at brenda-arkle dot demon dot co dot uk
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32759