On 4/25/05, Nicolai Guba <[EMAIL PROTECTED]> wrote: > Why bother with GCC at all? It is a horrible compiler which produces slow > code (and has many optimizations above -O2 broken). It's main advantages are > that it is portable and free. If you are looking for a compiler that > actually produces good binaries you are looking the wrong way IMO. > > ICC is a better compiler by far. Shame ICC support is only in a couple of > packages and not more widespread.
I wouldn't want to start a flamefest, but I've had a lot of experience with the ICC compiler over the last year working on the Battlefield 2 game engine (I used ICC under Linux) and I thought I'd add my two cents. There are a number of issues with using ICC on large C++ codebases. The most important ones I encountered are, in brief: - It sometimes generates invalid DWARF debugging sections, which crashes both GDB (all versions) and Intel's own debugger, idb. Not very helpful. - It sometimes generates broken assembly code (with duplicate assembly labels) that will not assemble, especially when you use floating point intrinsics (which are on by default). The only remedy is to move certain parts of expressions around. - It silently violates floating point IEEE requirements on the default optimization level (by using SSE single precision). This breaks many programs to the point where they see NaN values everywhere. I'm just trying to show that it's not all roses. For instance, I wouldn't expect something as large as openoffice or mozilla to compile and run successfully with ICC anytime soon unless major dev work goes into porting and babysitting those builds for ICC. On the positive side, ICC has excellent ANSI/ISO C++ support (it's based on a very good frontend which is also shared by Comaeu C++ IIRC), and when you care about speed more than correctness, it's very hard to beat. // Andreas -- [email protected] mailing list
