I know - this is why it was taking me 2-3 days to find a 100% reproducible bug (at least before I added debug printfs...). I just could not believe the gcc might be at fault.
Now, to be completely honest, first bug was present only on SPARC cpu on Solaris, x64 AMD was fine. We had to use gcc because one of libraries we were using was based on stlport compiled with gcc, so CC was out of question. I suppose that SPARC backend of gcc get a lot less testing. But second one on vanilla x64 intel linux and is still happening (gcc 4.8.2, but I think it was also checked to happen with 4.8.3). Magic option to avoid bug is -fno-tree-dse, whatever this means.
But yes, I was just unlucky - I have no doubts that gcc works fine for thousands programs out there. Guess what - it also works fine for both programs I have done, AFTER finding magic reordering of lines or command line option to get them to work. Who knows how many strange options are lurking in some of popular programs to work around similar issues