User account creation filtered due to spam.

Bug 50966 - [4.4/4.5/4.6 Regression] Missing 'is used uninitialized' warning (struct pointer dereference)
Summary: [4.4/4.5/4.6 Regression] Missing 'is used uninitialized' warning (struct poin...
Status: RESOLVED DUPLICATE of bug 50040
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.7.0
: P3 minor
Target Milestone: 4.4.7
Assignee: Richard Biener
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2011-11-02 18:40 UTC by Serge Belyshev
Modified: 2012-01-03 13:28 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-11-02 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Serge Belyshev 2011-11-02 18:40:47 UTC
Manuel, after your commit r139347 gcc doesn't warn about dereference of 'bar' in this testcase anymore:

struct foo
{
  int x;
};

int main (void)
{
  struct foo *bar;

  __builtin_printf ("%p\n", &bar->x);
  return 0;
}
Comment 1 Manuel López-Ibáñez 2011-11-02 19:19:39 UTC
Well, it did fix one of the oldest false positives in GCC:

        PR middle-end/179
        * tree-ssa.c (warn_uninit): Do not warn for variables that can be
        initialized outside the current module.
        (warn_uninitialized_var): Ignore left-hand side when walking the
        trees. Ignore address expressions. Examine VUSE operands in gimple
        statements with a variable declaration on the right-hand side.
testsuite/
        * gcc.dg/uninit-6.c (make_something): Remove XFAIL.
        * gcc.dg/uninit-6-O0.c (make_something): Remove XFAIL.
        * gcc.dg/uninit-B.c (baz): Remove XFAIL.
        * gcc.dg/uninit-B-2.c: New.
        * gcc.dg/uninit-B-O0-2.c: New.
        * gcc.dg/uninit-pr19430-O0.c: New.
        * gcc.dg/uninit-pr19430.c: New.
        * gcc.dg/uninit-pr19430-2.c: New.

so I think it is a good trade-off.

This may be easy to fix, but I don't have enough free time to look at it, and the uninitialized warning code has changed a lot since that revision, so anyone has as good chance to fix this as me. If you want some tips on where to start, just let me know.
Comment 2 Manuel López-Ibáñez 2011-11-02 19:24:44 UTC
BTW, this could actually be a duplicate of PR19430, if bar uninitialized use appears in a PHI op. One would need to look at the dumps and put a breakpoint at the warning point to see what is going on.
Comment 3 Richard Biener 2011-11-02 21:00:53 UTC
There is no dereference of bar in the testcase.  What is there is an
address computation based on bar, that should certainly be warned on.
And I do see that warning with trunk (but not with 4.5 or 4.6, I suppose
my uninit TLC patch somehow fixed this):

$ ./cc1 -quiet t.c -Wall
t.c: In function 'main':
t.c:10:20: warning: 'bar' is used uninitialized in this function [-Wuninitialized]

so, what is your real issue?
Comment 4 Richard Biener 2011-11-02 21:03:16 UTC
Btw, I'm talking about the fix for PR50040.
Comment 5 Richard Biener 2011-11-02 21:15:04 UTC
Mine (the patch for 50040 fixes it).
Comment 6 Richard Biener 2012-01-03 13:28:07 UTC
Dup.

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