Bug 43361

Summary: missing uninitialized warning without optimization (loop representation)
Product: gcc Reporter: Sebastian Mach <phresnel>
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED WONTFIX    
Severity: normal CC: manu, nocannedmeat, noufal
Priority: P3    
Version: 4.5.0   
Target Milestone: ---   
Host: (see details) Target: (see details)
Build: (see details) Known to work:
Known to fail: Last reconfirmed: 2010-03-14 15:45:50
Bug Depends on:    
Bug Blocks: 24639    

Description Sebastian Mach 2010-03-14 07:54:00 UTC
I've searched several of the other Wunitialized reports, but without deeper knowledge, I wasn't able to conclude whether this is a dup.

Note that even if i happens to be zero-initialized, it is only in this strapped-down testcase. In the program I am hacking, I got an out-of-bound of roughly 2^31 over an array of 6 elements, pretty deep in a expression template hierarchy.

================================================================================

//Tested with (-Wall -Wextra):
//  * g++-4.3 (Debian 4.3.4-6) 4.3.4
//  * g++-4.4 (Debian 4.4.2-9) 4.4.3 20100108 (prerelease)
//  * g++ (GCC) 4.5.0 20100306 (experimental)
#include <iostream>
int main () {
        int i;
        int array[10];
        //std::cout << i;               // get warning, okay
        for (; i<10; ++i) {             // no warning
                std::cout << i;         // no warning
                array [i] = i;          // no warning, really hurts
        }
        // sidenote: same results for 
        //   for (int i; i<N; ++i) {...}
}

================================================================================
Full triplets:

Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.4-6' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.3.4 (Debian 4.3.4-6)


Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.2-9' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.3 20100108 (prerelease) (Debian 4.4.2-9)


Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4.5-20100306/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.5-20100306/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.5-20100306 --enable-languages=c,c++ --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-checking --disable-nls --disable-multilib --enable-bootstrap --with-gcc --with-gnu-as --with-gnu-ld --with-gomp --with-lto
Thread model: posix
gcc version 4.5.0 20100306 (experimental) (GCC)
Comment 1 Manuel López-Ibáñez 2010-03-14 15:45:50 UTC
In GCC 4.3.x you need optimization enabled for Wuninitialized.

In GCC 4.4.1 and GCC 4.5 (trunk) I get warnings in line 6 with -O1 -O2 and -O3.

We do not get a warning with -O0 because the default definition appears in a PHI node:

<bb 2>:
  [pr43361.C : 6 : 3] goto <bb 4>;

<bb 3>:
  [pr43361.C : 7:19] std::basic_ostream<char>::operator<< ([pr43361.C : 7] &cout, i_1);
  [pr43361.C : 8:18] [pr43361.C : 8] array[i_1] = i_1;
  [pr43361.C : 6:3] i_4 = i_1 + 1;

<bb 4>:
  # i_1 = PHI <i_2(D)(2), [pr43361.C : 6:3] i_4(3)>
  [pr43361.C : 6:3] D.21125_3 = i_1 <= 9;
  [pr43361.C : 6:3] if (D.21125_3 != 0)
    goto <bb 3>;
  else
    goto <bb 5>;

<bb 5>:
  [pr43361.C : 0:0] D.21127_5 = 0;
  return D.21127_5;


This can be seen as a natural limitation of the analysis at -O0 or a problem with the way GCC represents loops:

for (init; test; next) { for-body }; is transformed to:

init:
 init;
 goto eval
body:
  for-body;
  next;
  goto eval;
eval:
 (test) ? goto body : goto finish;
finish:

So, although we know what "test" is evaluated at least once after init, GCC doesn't know that with -O0.

In any case, there is no trivial fix (but there is a workaround: use optimization).
Comment 2 Richard Biener 2010-03-15 11:27:33 UTC
(In reply to comment #1)
> In GCC 4.3.x you need optimization enabled for Wuninitialized.
> 
> In GCC 4.4.1 and GCC 4.5 (trunk) I get warnings in line 6 with -O1 -O2 and -O3.
> 
> We do not get a warning with -O0 because the default definition appears in a
> PHI node:
> 
> <bb 2>:
>   [pr43361.C : 6 : 3] goto <bb 4>;
> 
> <bb 3>:
>   [pr43361.C : 7:19] std::basic_ostream<char>::operator<< ([pr43361.C : 7]
> &cout, i_1);
>   [pr43361.C : 8:18] [pr43361.C : 8] array[i_1] = i_1;
>   [pr43361.C : 6:3] i_4 = i_1 + 1;
> 
> <bb 4>:
>   # i_1 = PHI <i_2(D)(2), [pr43361.C : 6:3] i_4(3)>
>   [pr43361.C : 6:3] D.21125_3 = i_1 <= 9;
>   [pr43361.C : 6:3] if (D.21125_3 != 0)
>     goto <bb 3>;
>   else
>     goto <bb 5>;
> 
> <bb 5>:
>   [pr43361.C : 0:0] D.21127_5 = 0;
>   return D.21127_5;
> 
> 
> This can be seen as a natural limitation of the analysis at -O0 or a problem
> with the way GCC represents loops:
> 
> for (init; test; next) { for-body }; is transformed to:
> 
> init:
>  init;
>  goto eval
> body:
>   for-body;
>   next;
>   goto eval;
> eval:
>  (test) ? goto body : goto finish;
> finish:
> 
> So, although we know what "test" is evaluated at least once after init, GCC
> doesn't know that with -O0.
> 
> In any case, there is no trivial fix (but there is a workaround: use
> optimization).

The trivial fix would be to compute post-dominator info and check if the
edge with the uninitialized use is executed on all paths from function
entry to exit (its source and destination post-dominate the entry bb).

Comment 3 Manuel López-Ibáñez 2010-03-15 13:42:37 UTC
(In reply to comment #2)
> 
> The trivial fix would be to compute post-dominator info and check if the
> edge with the uninitialized use is executed on all paths from function
> entry to exit (its source and destination post-dominate the entry bb).

You want to do that at -O0?
Comment 4 Richard Biener 2010-03-15 14:27:36 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > 
> > The trivial fix would be to compute post-dominator info and check if the
> > edge with the uninitialized use is executed on all paths from function
> > entry to exit (its source and destination post-dominate the entry bb).
> 
> You want to do that at -O0?

Not really.

Comment 5 Paolo Carlini 2011-09-28 22:40:56 UTC
Basing on the discussion, I'm closing this as wontfix.
Comment 6 Manuel López-Ibáñez 2013-10-21 12:08:03 UTC
*** Bug 58823 has been marked as a duplicate of this bug. ***
Comment 7 Manuel López-Ibáñez 2013-10-31 00:50:04 UTC
*** Bug 58236 has been marked as a duplicate of this bug. ***