JC>It seems to me that making such judgements based on a single program is
JC>a bit shortsighted.  Just FWIW, I've run a rather large benhmark
JC>However, each compiler produced quite poor code for at least one
JC>test.
That reminds me of the May/June 1990 issue of Programmer's Journal.
They benchmarked three compilers A, B, and C.  And they used reasonable
optimizations for each.
They then ran the sieve test in both the small and large memory models.
The first time they ran it, there was a clear winner.
They then made one minor change to the source (putting an automatic { 0
} initializer in the array declaration) and reran the tests, and this
time a different compiler was the clear winner!
They took another look at the source and made another minor change.
Instead of manually initializing the data with a for loop, they just use
memset().  And they reran the the tests, and this time the third
compiler came out the clear winner!
It turned out A, B, and C were three common compilers of the time.
It was a very interesting point of how just minor, reasonable changes in
code can totally change the benchmarking results, especially when the
benchmark is only a single program.  And how compiler makers can quite
'reasonably' proclaim their compiler produces the best code.
--- QScan/PCB v1.19b / 01-0162
---------------