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; }
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.
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.
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?
Btw, I'm talking about the fix for PR50040.
Mine (the patch for 50040 fixes it).
Dup. *** This bug has been marked as a duplicate of bug 50040 ***