[Bug middle-end/53917] New: Warning message line about variable points to place where variable doesn't occur

[Bug middle-end/53917] New: Warning message line about variable points to place where variable doesn't occur

[Paulo.Matos at csr dot com]

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

             Bug #: 53917
           Summary: Warning message line about variable points to place
                    where variable doesn't occur
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Paulo.Matos@csr.com


Created attachment 27771
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27771
Testcase

Hi,

I have noticed that when compiling the following test case (will attach to the
bug):

test1.c:
int a, b;
void fn1 ();
typedef enum
{
    READ_WRITE
} TAG_STATE;
TAG_STATE fn2 ();
void
fn3 ()
{
    int c;
    if (a)
        c = 0;
    else
        switch (fn2 ())
        case 0:
    c = 1;
    b = c;
    if (b)
        fn1 ();
}

gcc says:
$  gcc -Os -S -Wall test1.c
test1.c: In function 'fn3':
test1.c:19:8: warning: 'c' may be used uninitialized in this function
[-Wuninitialized]

However line 19 is 'if (b)'.

Used gcc46 but also reproducible with gcc47.

[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur

[Paulo.Matos at csr dot com]

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

--- Comment #1 from Paulo J. Matos <Paulo.Matos at csr dot com> 2012-07-10 16:37:20 UTC ---
Here's another example:
void fn1 ();
typedef struct
{
    int hdr[0];
} foo;
typedef enum
{
    READ_WRITE
} bar;
typedef struct
{
    struct
    {
        foo t1;
    } mp;
} foobar;
bar fn2 ();
typedef struct
{
    foobar tag_mem_config;
} tag;
static int
fn3 (foobar * p1)
{
    int valid;
    if (p1->mp.t1.hdr[0])
        valid = 0;
    else
        switch (fn2 ())
        case 0:
    valid = 1;
    return valid;
}
void
fn4 ()
{
    tag p_t1_rw_fsm_data;
    if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
        fn1 ();
}

GCC says:
test.c: In function 'fn4':
test.c:38:8: warning: 'valid' may be used uninitialized in this function
[-Wuninitialized]


Again, line 38 is: if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
In this case this looks like it's related to inlining.

[Bug middle-end/53917] Warning message line about variable points to place where variable doesn't occur

[Paulo.Matos at csr dot com]

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

--- Comment #2 from Paulo J. Matos <Paulo.Matos at csr dot com> 2012-07-10 16:38:22 UTC ---
Created attachment 27772
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27772
Another testcase (inlining issue)

[Bug middle-end/53917] Wuninitialized warning points to place where variable doesn't occur

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
                 CC|                            |msebor at gcc dot gnu.org
             Status|NEW                         |RESOLVED

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
The underlying problem with the test case in comment #1 is the same as the one
discussed in bug 40635 comment #13.  With the patch there applied, GCC issues a
note after the warning that points to the uninitialized variable:

pr53917-c1.c: In function ‘fn4’:
pr53917-c1.c:38:8: warning: ‘valid’ may be used uninitialized
[-Wmaybe-uninitialized]
   38 |     if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
      |        ^
pr53917-c1.c:25:9: note: ‘valid’ was declared here
   25 |     int valid;
      |         ^~~~~

There may be more that can be done to improve the context of the warning to
make it clearer but we can track those improvements separately.

*** This bug has been marked as a duplicate of bug 40635 ***