gcc-4.1 produces a warning for the following testcase. (testcase uses headers from boost-1.34.0). $ cat multi_index_test.cpp #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/identity.hpp> #include <boost/multi_index/member.hpp> #include <vector> using namespace boost; using namespace boost::multi_index; struct X { int value; bool operator < ( X const& e) const; }; typedef multi_index_container < X, indexed_by < ordered_unique< identity< X > >, ordered_non_unique< member< X, int, &X::value > > > > C; extern C f( std::vector< X > const& v ) { return C( v.begin(), v.end() ); } $ x86_64-gnu-linux-g++ \ -I/local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include \ multi_index_test.cpp -O1 -Wall --save-temps -c /local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include/boost/multi_index/ordered_index.hpp: In member function 'std::pair<typename boost::multi_index::detail::multi_index_base_type<Value, IndexSpecifierList, Allocator>::type::node_type*, bool> boost::multi_index::multi_index_container<Value, IndexSpecifierList, Allocator>::insert_(const Value&, typename boost::multi_index::detail::multi_index_base_type<Value, IndexSpecifierList, Allocator>::type::node_type*) [with Value = X, IndexSpecifierList = boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<X>, mpl_::na, mpl_::na>, boost::multi_index::ordered_non_unique<boost::multi_index::member<X, int, &X::value>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, Allocator = std::allocator<X>]': /local/devel/buildenv41/x86_64-gnu-linux/boost-stdc++-1.34.0/include/boost/multi_index/ordered_index.hpp:566: warning: 'inf.boost::multi_index::detail::ordered_index<boost::multi_index::identity<X>, std::less<X>, boost::multi_index::detail::nth_layer<1, X, boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::identity<X>, mpl_::na, mpl_::na>, boost::multi_index::ordered_non_unique<boost::multi_index::member<X, int, &X::value>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<X> >, boost::mpl::vector0<mpl_::na>, boost::multi_index::detail::ordered_unique_tag>::link_info::side' may be used uninitialized in this function as far i can the warning comes from: bool link_point(key_param_type k,link_info& inf,ordered_unique_tag) { (...) else{ inf.pos=yy->impl(); <== partial initialziation of link_info&. return false; } } in fact, all use cases of link_point use only inf.pos when {hinted_,}link_point returns false. (...) if(!link_point(key(v),inf,Category())){ return node_type::from_impl(inf.pos); (...) node_type* insert_(value_param_type v,node_type* position,node_type* x) { link_info inf; if(!hinted_link_point(key(v),position,inf,Category())){ return node_type::from_impl(inf.pos); (...) gcc-3.4.5 and 4.2 works fine (no warning), but 4.1.2 fails. 4.0 and 4.3 wasn't tested.
Created attachment 13730 [details] testcase
This is caused by two things, jump threading and inlining. If we jump thread more, we no longer get the warning which is what you are seeing in 4.2.1.
(In reply to comment #2) > This is caused by two things, jump threading and inlining. If we jump thread > more, we no longer get the warning which is what you are seeing in 4.2.1. is there any possibility to increase the depth of this analysis in 4.1.x? some compile-time constant hardcoded in sources, or sth?
(In reply to comment #2) > This is caused by two things, jump threading and inlining. If we jump thread > more, we no longer get the warning which is what you are seeing in 4.2.1. > the latest gcc 4.2 also produces this warning.
Created attachment 13789 [details] preprocessed testcase
(In reply to comment #5) > Created an attachment (id=13789) [edit] > preprocessed testcase > :-( I cannot compile this testcase manu@localhost:~/gcc$ g++ -c -O1 -Wall pr32395.ii -Wfatal-errors /usr/include/c++/4.2.0/x86_64-pld-linux/bits/c++config.h:149: error: expected `=' before ‘__attribute__’ manu@localhost:~/gcc$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)
(In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=13789) [edit] > > preprocessed testcase > > > > :-( I cannot compile this testcase it works with my gcc-4.2.1-20070719.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > Created an attachment (id=13789) [edit] > > > preprocessed testcase > > > > > > > :-( I cannot compile this testcase > > it works with my gcc-4.2.1-20070719. Perhaps is because my target is i*86-linux-gnu? Could you reprocess it for that, please?
Created attachment 14095 [details] preprocessed testcase for 32-bits targets.
Manuel, ping, do you working on it? i've posted preprocessed 32-bit testaces for you over month ago ;) btw. PR32368 exposes this bug.
(In reply to comment #10) > Manuel, ping, do you working on it? > i've posted preprocessed 32-bit testaces for you over month ago ;) > btw. PR32368 exposes this bug. > Sorry, I am probably doing something wrong but I cannot get it to compile. Weird. manuel@gcc11:~$ 128590/build/gcc/cc1plus src/multi_index_test.ii -O1 -Wall -Wfatal-errors In file included from /usr/include/c++/4.2.1/bits/stl_algobase.h:73, from /usr/include/c++/4.2.1/algorithm:66, from /usr/include/boost/multi_index_container.hpp:20, from multi_index_test.cpp:2: /usr/include/c++/4.2.1/bits/cpp_type_traits.h: At global scope: /usr/include/c++/4.2.1/bits/cpp_type_traits.h:346: error: expected identifier before ‘__is_pod’ and manu@localhost:~/$ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4) manu@localhost:~/$ g++ -Wall -O1 -c multi_index_test.ii -Wfatal-errors /usr/include/c++/4.2.1/x86_64-pld-linux/32/bits/c++config.h:149: error: expected `=' before ‘__attribute__’ compilation terminated due to -Wfatal-errors.
(In reply to comment #11) > /usr/include/c++/4.2.1/bits/cpp_type_traits.h:346: error: expected identifier > before ‘__is_pod’ __is_pod is only implemented on mainline, not 4.2.1. W.
Created attachment 14903 [details] testacase for /opt/gcc43/bin/g++ 32395.ii -Wall -c -O1 -m32
> :-( I cannot compile this testcase please try the latest testcase.
(In reply to comment #14) > > :-( I cannot compile this testcase > > please try the latest testcase. > Thanks. It compiles fine now. The weirdest thing is that I cannot see the uninitialized warning but I can see the "note: was declared here" message and also the line were the warning should appear. So something is going very wrong here.
Somehow after SRA we end up creating a PHI node with an empty definition: # BLOCK 5 freq:2931, starting at line 7057 # PRED: 276 [98.0%] (true,exec) 3 [98.0%] (true,exec) # inf$sideD.88720_393 = PHI <inf$sideD.88720_1256(276), inf$sideD.88720_1476(D)(3)> This node comes from the end of BB 3: # MPT.561D.88709_1630 = VDEF <MPT.561D.88709_1629> { MPT.561D.88709 } [pr32395-0.ii : 26871] thisD.73371_2(D)->node_countD.70698 = 0; # VUSE <MPT.561D.88709_1630> { MPT.561D.88709 } [pr32395-0.ii : 27027] hint$nodeD.85841_101 = D.84656_69->D.70734.memberD.68890; [pr32395-0.ii : 26876] if (last$_M_currentD.85838_10 != first$_M_currentD.85837_463) goto <bb 5>; else goto <bb 285>; # SUCC: 5 [98.0%] (true,exec) 285 [2.0%] (false,exec) I really cannot see in this huge testcase how we end up building this. However, not even after all passes we remove the uninitialized use (and the edges going to the block have a rather high probability). So, this is does not seem a bug, just a case were GCC is not smart enough. More optimizations, more cases we could catch. We will never catch them all. I would call it a Halting Problem case and suspend it (probably add it with xfail to the testsuite). ;-) That it worked before just shows a possible optimisation regression with respect to this code. But in such a huge testcase, it is hard to see what regressed.
recent 4.4/4.5 compiles '32395.ii -Wall -c -O1 -m32' cleanly, 4.3 still warns.
Pawel, I thank you for the report, but I really do not see how we can use this bug report. The testcase is huge, so we cannot add it to the testsuite to avoid regressing. If you can find a reduced testcase http://gcc.gnu.org/bugs/minimize.html or starts failing again, please reopen, meanwhile, I am closing this as FIXED in GCC 4.5.