Attached is a small program that computes some values and puts them in a std::vector. The values are stored in the `init' variable, but when optimizations are enabled, the data actually added to the vector is garbage.

I've done a little testing and the problem exists when compiling with -O and -O2, but when compiling with -O0 or -O -fno-tree-copy-prop the bug disappears. (This is also the case when compiling with -fmudflap.)

To reproduce the bug, take the attached test.cpp and do:
  $ g++ -O -o broken test.cpp
  $ ./broken
  broken: test.cpp:55: int main(): Assertion `res[0] == 5' failed.
  Aborted

For comparison, you can run:
  $ g++ -O -fno-tree-copy-prop -o working test.cpp
  $ ./working

And see that it works fine. Running the broken binary trough valgrind gives a "conditional jump or move depends on uninitialised value" message.

I'll attach (part of) the output of compiling with -fdump-tree-optimized. The code is similar in both versions, but I think the problem is here:

<bb 16>:
  init_lsm.129 = l / i - i / 2;
  if (init_lsm.129 >= 0)
    goto <bb 17>;
  else
    goto <bb 25>;

<bb 17>:
  init = init_lsm.129;
  init = init_lsm.130;

As you can see, the correct value in `init_lsm.129' is assigned to `init' only to be overwritten by the uninitialized data in `init_lsm.130'. The working version looks similar but seems to have the last two statements reversed, so that the correct value ends up in `init'.

I'm using gcc version 4.3.3 (Gentoo 4.3.3 p1.0, pie-10.1.5), but the problem was first seen on a system runing GCC 4.1.x (or lower); not my own system so I can't check exactly, but it probably doesn't matter. Since the bug seems to be in the C++ front-end, it occurs when producing 64-bit as well as 32-bit binaries.

Hopefully, you are able to figure out what goes wrong. If this is a genuine bug, it seems to affect a wide range of compiler versions. Let me know if you need any more information, and I'll be happy to help.