Some various complaints: 1. http://hardwarebug.org/ http://hardwarebug.org/ Mans covers a lot of incredible retardation here, particularly on ARM and PPC pla

Some various complaints: 1. http://hardwarebug.org/ http://hardwarebug.org/ Mans covers a lot of incredible retardation here, particularly on ARM and PPC platforms, such as cases where GCC generates 2-3 times the number of instructions necessary for no good reason. 1b. http://x264dev.multimedia.cx/?p=62#comments http://x264dev.multimedia.cx/?p=62#comments Until extremely recently, GCC's handling of multiplications of non-native types has been hilariously bad, up to and including loading the value zero into a register and multiplying by it. 2. General bugginess all over the place, particularly with non-x86 platforms. The number of failed unit tests for ffmpeg with gcc 4.4 on PPC64 was staggering. Of course, commercial compilers are buggy as well, so this is not really exclusive to GCC; the latest ICC miscompiles large chunks of ffmpeg and Mans has been quite busy submitting bug reports for armcc. 3. Tendency to get worse with every new release; this trend was finally reversed with 4.3 and 4.4, the latter of which was the first compiler to beat 2.9.5 in performance (in ffmpeg, at least): http://multimedia.cx/eggs/last-performance-smackdown-for-awhile/ http://multimedia.cx/eggs/last-performance-smackdown-for-awh... 4. Tendency to declare obvious bugs to be not bugs; for example, failures in the register allocator for inline assembly in which it couldn't allocate 7 registers for the inline assembly despite 7 registers being available (but only inconsistently, on some platforms and some versions, for no apparent reason). Don't have links to the gcc bugtracker on me for these. 5. Incredibly bad optimization on non-x86 architectures. ARM is a particularly horrendous example, where we found the following happening when compiling x264: a) In the most important DSP function in the program, SATD, GCC unrolled the loop completely. This is related to the fact that there are no loop unrolling heuristics for ARM--and instead of just disabling loop unrolling, the decision is binary ("fully unrolled" vs "not unrolled"), with the former being far too heavily weighted in favor of. b) GCC then completely failed to allocate registers correctly, resulting in an enormous number of unnecessary loads/stores to the stack. c) The function's speed was cut in half due to this. Other issues include GCC's inability to consistently use the ARM's "free shift," up to and including putting shifts on register X right next to another op on register X despite the ability of even a simple peephole optimizer to merge the two instructions. Also, GCC seems generally bad at three-operand architectures; one will find many redundant moves between registers on ARM, which generally should almost never exist in a three-operand instruction set. Here's an example similar to something I've seen (I don't recall the exact instructions): add r0, r0, r7 mov r1, r0 mov r0, [r3] Clearly, this example can be reduced to: add r1, r0, r7 mov r0, [r3]