Bug 33802 - bogus "is used uninitialized" (VOPs) (inlining)
Summary: bogus "is used uninitialized" (VOPs) (inlining)
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks: Wuninitialized
  Show dependency treegraph
 
Reported: 2007-10-17 18:38 UTC by bagnara
Modified: 2012-02-09 07:26 UTC (History)
4 users (show)

See Also:
Host: x86_64-unknown-linux-gnu
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-12-22 18:02:52


Attachments
(Big) testcase that allows to reproduce the problem. (227.07 KB, application/octet-stream)
2007-10-17 18:40 UTC, bagnara
Details
New testcase showing the problem with GCC 4.3.0 (226.02 KB, application/x-bzip2)
2008-01-07 19:32 UTC, bagnara
Details
Reduced testcase (16K) GCC 4.3 (2.50 KB, patch)
2008-02-04 20:37 UTC, Manuel López-Ibáñez
Details | Diff
Test for a valid testcase (171 bytes, text/plain)
2008-02-04 20:39 UTC, Manuel López-Ibáñez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bagnara 2007-10-17 18:38:59 UTC
For the attached testcase, g++ gives a warning saying "`z' is used uninitialized in this function" (_is_ used uninitialized, not _may be_ used uninitialized)
in the statement marked with (***) below.  However, `z' is indeed
initialized by the mul() function template, which takes the first
argument by (non-const) reference:

template <typename To_Policy, typename From1_Policy, typename From2_Policy, typename Type>
inline Result
add_mul_int(Type& to, const Type x, const Type y, Rounding_Dir dir) {
  Type z;
  Result r = mul<To_Policy, From1_Policy, From2_Policy>(z, x, y, dir);
  switch (r) {
  case V_NEG_OVERFLOW:
  case V_LT:
    if (to <= 0) {
      to = z;  (***)
      return r;
    }

To reproduce:

$ bunzip2 bug.cc.bz2 
$ md5sum bug.cc
bb3e86d1d865d1b661dd86da3456c909  bug.cc
$ g++ -Wall -O2 -c bug.cc
bug.cc: In function ‘void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]’:
bug.cc:37941: warning: ‘z’ is used uninitialized in this function
$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)
$ 

The file bug.cc.t28.ssa is 944683 bytes once compressed: I will attach it if required.
Comment 1 bagnara 2007-10-17 18:40:50 UTC
Created attachment 14366 [details]
(Big) testcase that allows to reproduce the problem.
Comment 2 Andrew Pinski 2007-10-17 18:46:07 UTC
I doubt this is not an incorrect warning.
Comment 3 Richard Biener 2007-10-17 21:23:38 UTC
"I doubt this is not an incorrect warning."

what? :)
Comment 4 Manuel López-Ibáñez 2007-12-22 18:02:51 UTC
(In reply to comment #1)
> Created an attachment (id=14366) [edit]
> (Big) testcase that allows to reproduce
> 
I can't compile the testcase with cc1plus 4.3 revision 130379. I get a lot of warnings and a few errors. Perhaps I need to include something else ?


Anyway, the relevant SSA is:


 # BLOCK 195, starting at line 37941
  # PRED: 194 (true)
<L168>:;
  #   VUSE <zD.225363_219>;
  [/home/manuel/src/pr33802.C : 37941] z.1689D.225422_240 = zD.225363;
  [/home/manuel/src/pr33802.C : 37941] *toD.225359_119 = z.1689D.225422_240;
  [/home/manuel/src/pr33802.C : 37942] D.225423_241 = rD.225364_141;
  goto <bb 213> (<L186>);
  # SUCC: 213 (fallthru)

Wuninitialized cannot handle virtual operands, so it doesn't understand that z could have been initialized. Funny enough, this is exactly the opposite of bug 179 but both SSA dumps look very similar. I really don't understand why we warn in one case and not in the other.

By the way, what does 

  #   VUSE <zD.225363_219>;

exactly means? I cannot find any other mention of zD.225363_219.
Comment 5 bagnara 2008-01-07 19:20:28 UTC
Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2).  For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228.

Here is what happens (note that, differently from what was the case, now the warning is give three times in a row):

$ bunzip2 bug2.cc.bz2 
$ md5sum bug2.cc
63b807d5f4dc8d88c00d84a2e951f048  bug2.cc
$ g++ -W -Wall -Wno-parentheses -O2 -c bug.cc
bug.cc: In function ‘void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]’:
bug.cc:3675: warning: ‘z’ is used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc: In member function ‘Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_Shape<T>::relation_with(const Parma_Polyhedra_Library::Generator&) const [with T = __gmp_expr<__mpq_struct [1], __mpq_struct [1]>]’:
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
$ 


Comment 6 bagnara 2008-01-07 19:30:10 UTC
Please, forget comment #5.  Let me try again.

Indeed the testcase does not compile with GCC 4.3 (while compiling perfectly with GCC 4.0, 4.1 and 4.2).  For some reason, GCC 4.3 dislikes the implementation of the STL that is shipped with previous versions. I have thus reconstructed the testcase by compiling the non-preprocessed sources with GCC version 4.3.0 20071228.

Here is what happens (note that, differently from what was the case, now the warning is give three times in a row):

$ bunzip2 bug2.cc.bz2 
$ md5sum bug2.cc
63b807d5f4dc8d88c00d84a2e951f048  bug2.cc
$ g++ -W -Wall -Wno-parentheses -O2 -c bug2.cc
bug.cc: In function ‘void Parma_Polyhedra_Library::add_mul_assign(Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&, const Parma_Polyhedra_Library::Checked_Number<T, P>&) [with T = long int, Policy = Parma_Polyhedra_Library::Checked_Number_Default_Policy]’:
bug.cc:3675: warning: ‘z’ is used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc: In member function ‘Parma_Polyhedra_Library::Poly_Gen_Relation Parma_Polyhedra_Library::Octagonal_Shape<T>::relation_with(const Parma_Polyhedra_Library::Generator&) const [with T = __gmp_expr<__mpq_struct [1], __mpq_struct [1]>]’:
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
bug.cc:3669: warning: ‘z’ may be used uninitialized in this function
bug.cc:3669: note: ‘z’ was declared here
$ g++ --version
g++ (GCC) 4.3.0 20071228 (experimental)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ 
Comment 7 bagnara 2008-01-07 19:32:06 UTC
Created attachment 14894 [details]
New testcase showing the problem with GCC 4.3.0
Comment 8 Manuel López-Ibáñez 2008-02-01 16:28:24 UTC
(In reply to comment #6)
> Here is what happens (note that, differently from what was the case, now the
> warning is give three times in a row):

 
The "is used" warning is the same issue with virtual operands. The relevant part is this:

  # BLOCK 4, starting at line 3675
  # PRED: 3 (true)
  # LOADS:  { zD.189596 }
  [bug.cc : 3675] z.1883D.189607_8 = zD.189596;
  [bug.cc : 3675] *toD.188165_6(D) ={v} z.1883D.189607_8;
  [bug.cc : 3676] D.189608_9 = rD.189597_4;
  [bug.cc : 3676] goto <bb 10>;
  # SUCC: 10 (fallthru)

We see that zD.189596 has an empty definition, which is wrong since it has been passed by reference in a previous BB. Again, it won't be fixed until we teach Wuninitialized about VOPS.


The "may be used" warnings appear after applying inline, so we end up with something like:

  # BLOCK 25 freq:10000, starting at line 3670
  # PRED: 3 [100.0%]  (fallthru,exec) 6 [33.0%]  (false,exec) 7 [100.0%]  (fallthru,exec) 8 [100.0%]  (fallthru,exec) 12 [33.0%]  (false,exec) 13 [100.0%]  (fallthru,ex\
ec) 15 [69.0%]  (false,exec) 16 [100.0%]  (fallthru,exec) 19 [33.0%]  (false,exec) 20 [100.0%]  (fallthru,exec) 22 [69.0%]  (false,exec) 23 [100.0%]  (fallthru,exec) 24\
 [100.0%]  (fallthru,exec)
  # zD.203060_41 = PHI <zD.203060_58(3), zD.203060_50(D)(6), zD.203060_51(7), zD.203060_52(8), zD.203060_50(D)(12), zD.203060_53(13), zD.203060_50(D)(15), zD.203060_54(\
16), zD.203060_50(D)(19), zD.203060_55(20), zD.203060_50(D)(22), zD.203060_56(23), zD.203060_57(24)>
  # D.222111_38 = PHI <4(3), 33(6), 2(7), 4(8), 33(12), 2(13), 18(15), 1(16), 33(19), 2(20), 18(22), 1(23), 4(24)>
  D.222156_40 = D.222111_38;
  [bug.cc : 3670] rD.203116_7 = D.222156_40;
  [bug.cc : 3671] r.1882D.203125_9 = (intD.2) rD.203116_7;
  [bug.cc : 3671] switch (r.1882D.203125_9)


Whether that is a correct PHI, I cannot tell because the testcase is too huge for me to understand how that happened. Yet, we should not be warning for each PHI operand, at a minimum. 
Comment 9 Manuel López-Ibáñez 2008-02-01 16:29:52 UTC
Changing subject to something more informative.
Comment 10 Richard Biener 2008-02-01 16:48:51 UTC
# zD.203060_41 = PHI <zD.203060_58(3), zD.203060_50(D)(6), zD.203060_51(7),
zD.203060_52(8), zD.203060_50(D)(12), zD.203060_53(13), zD.203060_50(D)(15),
zD.203060_54(\
16), zD.203060_50(D)(19), zD.203060_55(20), zD.203060_50(D)(22),
zD.203060_56(23), zD.203060_57(24)>

The PHI is correct, you get one arg per incoming edge.  But yes, we should
warn only once for default definitions that appear multiple times in
single PHI nodes and also in mulitple PHI nodes.  But we mark the
var with TREE_NO_WARNING, so it should not warn multiple times here.
Comment 11 Manuel López-Ibáñez 2008-02-01 18:16:10 UTC
I tried to debug this but it just keep spilling gibberish, which makes it hard to debug under emacs. Is there a commandline option to stop C++ front-end hyper-verbose output? 
Comment 12 Manuel López-Ibáñez 2008-02-01 18:21:07 UTC
(In reply to comment #10)
> 
> The PHI is correct, you get one arg per incoming edge.

What I meant by correct is that there is some reasonable way to end up with this PHI containing an empty definition when there is no uninitialized use of a variable. Sorry for the confusion.
Comment 13 Manuel López-Ibáñez 2008-02-04 20:37:17 UTC
Created attachment 15095 [details]
Reduced testcase (16K) GCC 4.3

I can't reduce this further, so I post it here in case someone wants to give it a try. I am just looking to fix the duplicated "may be uninitialized" warning. 

This testcase won't be useful to track why there is a warning. And I don't know how to reduce the original testcase to do that. It is too big for me to analyse manually and automatic reduction tools will likely remove initialisations and make the warning correct.
Comment 14 Manuel López-Ibáñez 2008-02-04 20:39:56 UTC
Created attachment 15096 [details]
Test for a valid testcase

This is the test I am using for reducing the testcase. If you change something and run:

./pr33802.sh new.ii && echo OK

and don't get an OK, then the testcase is not valid anymore. Otherwise, great!