Bad adjacency_iterator with -O2, -m64 and gcc 3.2.2 on an opteron
Hi, compiling and linking the following program on a opteron with the following command and the operating system red hat 3 (current enterprise server version) gcc-3.2.2 -c -I. -I../source -I./boost_1_32_0 -O2 -m64 boosttest.cc -o boosttest.o gcc-3.2.2 -m64 -o boosttest boosttest.o -lstdc++ will cause, that the program runs into an endles loop. I figured out, that the pointer in VIter which is compared when comparing VIter and VIterEnd is damaged. With a lot of differen gcc versions and also in 32 bit mode and with lower optimization it works fine. The problem is, I have to run it also compiled with gcc 3.2.2. Is it an optimization bug in the compiler or any mistake I made or a problem in the boost? I was looking for a hint on the net but without success. Can anybody help? Thanks ------------------------------------------------------------------------------- int main (int argc, char **argv) { typedef boost::adjacency_list < boost::listS, boost::listS, boost::undirectedS
my_graph2_t;
my_graph2_t MyGraph2;
boost::graph_traits
Michal Simecek wrote:
compiling and linking the following program on a opteron with the following command and the operating system red hat 3 (current enterprise server version)
gcc-3.2.2 -c -I. -I../source -I./boost_1_32_0 -O2 -m64 boosttest.cc -o boosttest.o gcc-3.2.2 -m64 -o boosttest boosttest.o -lstdc++
will cause, that the program runs into an endles loop. I figured out, that the pointer in VIter which is compared when comparing VIter and VIterEnd is damaged. .. tie(VIter, VIterEnd) = boost::adjacent_vertices(MyVDescriptor, MyGraph2);
while ( VIter != VIterEnd ) { std::cout << "loop ..." << std::endl; ++VIter; }
What does "damaged" means? Is it "damaged" at the time of creation. If not, you should be able to single step in the debugger, and locate the point where it's damaged. Or you can set hardware watch point and the memory location that's damaged and let gdb/processor find the point that damages the variable. Once that one, we might try to investigate further.
Is it an optimization bug in the compiler or any mistake I made or a problem in the boost?
Impossible to tell without more specific details. - Volodya
Michal Simecek wrote:
compiling and linking the following program on a opteron with the following command and the operating system red hat 3 (current enterprise server version)
gcc-3.2.2 -c -I. -I../source -I./boost_1_32_0 -O2 -m64 boosttest.cc -o boosttest.o gcc-3.2.2 -m64 -o boosttest boosttest.o -lstdc++
will cause, that the program runs into an endles loop. I figured out, that the pointer in VIter which is compared when comparing VIter and VIterEnd is damaged. .. tie(VIter, VIterEnd) = boost::adjacent_vertices(MyVDescriptor, MyGraph2);
while ( VIter != VIterEnd ) { std::cout << "loop ..." << std::endl; ++VIter; }
What does "damaged" means? Is it "damaged" at the time of creation. If not, you should be able to single step in the debugger, and locate the point where it's damaged. Or you can set hardware watch point and the memory location that's damaged and let gdb/processor find the point that damages the variable.
"demaged" means, that it dont looks like a valid address, but this is just a guess. But a fact is that the value does not change when the iterator gets increased. Debugging is a good idea, but i had the hope to find somebody who did it already, because its not funny to debug optimized code. And without optimisation everything works fine.
Once that one, we might try to investigate further.
Is it an optimization bug in the compiler or any mistake I made or a problem in the boost?
Impossible to tell without more specific details.
Yes, I see what you mean, but it is hard to find more specific details. Thanks, Michal
- Volodya
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Michal Simecek
-
Vladimir Prus