Intel C/C++ Compiler 8.0 Released

Peorth writes "Intel has released version 8.0 of their Intel C/C++ compiler for both Windows and Linux. This release has been rumored for a long time to contain 100% GCC source and binary compatibility. It seems great strides have been made in advancement of that goal, as well as of its performance, but it may have a long way to go yet. Has anyone had experiences with it yet, either good or bad?"

Comments

How fast on non intel machines ?

[bug1]

How bloated are the static binaries ICC produces ?

Code portability is important.

If you dont care about code portability and all you want speed write in assembler, not C or C++

ICC ay be usefull to a niche market, but it doesnt have a long term future.

Re:do try to keep up

[ciaran_o_riordan]

> How is staying out of jail an argument against using Intel's compiler?

If you have a copy of icc, and a friend or family member asks for a copy, what do you do?
You could say "No, I promised Intel that I wouldn't give a copy to you or anyone else". Or you could break the promise to Intel and help your friend. I think the latter is the lesser of two evils, but it's easier to simply avoid this dilema by not making that promise to Intel in the first place.

> As for "knowing what your compiler is doing"

This is a point I made in a post a little further down the page. My reason isn't really covered by your three options. I trust Intel to make a compiler, running the binary is probably not harmful on it's own, and I'm not really interested in reading the code. BUT:

My concern is over what the compiler might do to my code during compilation. Intel is part of the Trusted Computing Group. Will the compiler silently add a DRM signature? will a later version do so?

I'm not suggesting a tinfoil hat conspiracy, but if Trusted Computing became company policy, it could be added to the compiler as a mandatory feature. Maybe it's already in there. I don't like the idea of kernels, libc, gnupg, ssh, lsh, etc. being compiled by a black box.