Quoting Jeff Law <l...@redhat.com>:
Use of floating point within the compiler (we generally avoid it), unstable qsort (again, we generally try to avoid it), hashing issues, particularly with pointers, etc etc.
The floating point issues also mean that the compiler behaviour is not defined by the standard; the others are even worse, potentially or manifestly causing the compiler to have random output (in particular when address space randomization is in effect, and/or when shared libraries are moving around). These things can make debugging the compiler, checking pre-compiled headers, and/or marginal performance comparisons so much harder that it is easiest to fix the unpredictability issue first. Moreover, when a hashing issue is about generating different hashes for things that compare equal, if the issue doesn't cause wrong code, it is likely to cause missed optimizations (with rare instances when hash collisions make things work). So, I would say that inconsistent / unpredictable compilation results are generally worth fixing, assuming you have or can make a suitable patch.
For those reasons and many more, we don't try to guarantee that a compiler running on different hosts will generate 100% identical target code.
Of course, guarantees are rare for open-source projects (and for most kinds of software, for that matter), and also, on a pragmatic level, the impact from inconsistent compiler output on end-users tends to be low, so these issues tend to only get addressed when they impact compiler development. As GCC 3.2.3 is fairly old, if the original poster really wants it fixed, he'll have to hack the compiler himself, or hire somebody to do it for him.
