Bug 56748 - Bogus uninitialized warning with nested if condition
Bogus uninitialized warning with nested if condition
Product: gcc
Classification: Unclassified
Component: middle-end
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
Reported: 2013-03-26 20:26 UTC by Rich Townsend
Modified: 2013-10-30 21:32 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:

Sample code producing bogus warning (244 bytes, text/x-fortran)
2013-03-26 20:26 UTC, Rich Townsend

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Townsend 2013-03-26 20:26:34 UTC
Created attachment 29736 [details]
Sample code producing bogus warning

In the attached code, compilation with the following args:

gfortran -O2 -fcheck=all -Wall -c test_uninit.f90

...produces the following warning:

test_uninit.f90: In function ‘mysub’:
test_uninit.f90:13:0: warning: ‘b.0’ may be used uninitialized in this function [-Wmaybe-uninitialized]
      print *, b

The warning goes away if any of the following modifications are made:

*) any of the compilation flags is omitted
*) the stop statement in the code is commented out
*) the variable 'b' is made non-optional (and the PRESENT check is removed)
*) the variable 'b' is made a scalar

gfortran -v:
Using built-in specs.
Target: x86_64-apple-darwin11.4.2
Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 4.8.0 20130314 (experimental) (GCC)
Comment 1 Tobias Burnus 2013-03-27 08:26:31 UTC
First remark: Bogus uninitialized warnings can not always be prevented. - It is a extremely complex problem, where a few false warnings (and many missed warnings) are unavoidable. Still, one should do better.

If one looks at the dump (-fdump-tree-original, i.e. a C-like output of the internal representation), one sees:

mysub (struct array1_integer(kind=4) & restrict a,
       struct array1_integer(kind=4) * b)

  if (b != 0B && (integer(kind=4)[0:] * restrict) b->data != 0B)
        b.0 = (integer(kind=4)[0:D.1925] * restrict) b->data;
  if (b != 0B && (integer(kind=4)[0:] * restrict) b->data != 0B)
              if (b != 0B && (integer(kind=4)[0:] * restrict) b->data != 0B)
                  // Here are some run-time checks, enabled by -fcheck=all
          parm.10.data = (void *) &(*b.0)[0];
          _gfortran_transfer_array_write (&dt_parm.9, &parm.10, 4, 0);

As all "if" conditions are the same, b.0 is never uninitialized. However, nesting the same "b != NULL" seems to confuse the uninitialized diagnostic.