[Bug tree-optimization/51444] New: [4.4 Regression]: Spurious "is used uninitialized" warning for structure with bitfields

[hp at gcc dot gnu.org]

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

             Bug #: 51444
           Summary: [4.4 Regression]: Spurious "is used uninitialized"
                    warning for structure with bitfields
    Classification: Unclassified
           Product: gcc
           Version: 4.4.7
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hp@gcc.gnu.org
              Host: x64_86-unknown-linux-gnu
            Target: cris-axis-elf, x64_86-unknown-linux-gnu


Created attachment 26012
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26012
testcase to be compiled with "-O2 -Wuninitialized"

For 4.4 and the attached code, spurious warnings are emitted when compiling
with -O2 -Wuninitialized (or -O2 -Wall):
/n/slask/hp_tmp/foo.c: In function 'foo2d2':
/n/slask/hp_tmp/foo.c:63: warning: 'r' is used uninitialized in this function
/n/slask/hp_tmp/foo.c: In function 'foo':
/n/slask/hp_tmp/foo.c:44: warning: 'r' is used uninitialized in this function

There should be no warnings, as the structures are initialized; one member
explicitly and the rest implicitly to zero.

Note the similarity between the structures and the three functions: by adding
another member *after* the used one (adjusting the size of one member, so the
whole struct fits within 32 bits) the warning disappears, but reappears when
the "use" is changed to that new last member.  All targets; presence on
4.4-branch verified for r180236.
Absence is verified for 4.3 r181718, 4.5 r181718, 4.6 r182058 and trunk
r182065.

Setting component to "tree-optimization" somewhat speculatively but on the
grounds that -O2 is required and the warning appears for at least both host
x86_64 (at least in F 12 gcc-4.4.3-4.fc12.x86_64 as well as "Debian 4.4.5-8")
and cris-elf (svn revisions above).

I'm not sure this bug is worth fixing since it's already fixed in two later
major releases, mostly providing this PR as a placeholder: I couldn't find an
existing matching PR.