I know that (from previous threads), and that is why you are in a position to give useful technical information about the differences between compilers. Tell us why Keil's debugger is much better than Rowley's, or IAR's IDE saves time and therefore money. All I'm asking is that you give us good reasons to choose the tools you recommend, rather than just saying you dislike gcc.
I can give plenty of criticism of gcc (some general to gcc, some regarding other parts of the toolchain, others specific to particular targets).
There are fanatics for all sorts of products, but most people who use gcc are aware of its pros and cons, and choose to use it despite its warts. Sometimes that is because of particular requirements (such as the host operating system, or availability of source code, lack of licensing issues, price), and sometimes they have a free choice but feel gcc provides the best value for money (including time), or produces the best code, or is most compatible with other tools.
The people providing gcc toolchains, especially those providing them for free, are (in my experience) often far more honest about limitations or problems than people selling commercial tools.
Ok, no one is entirely unbiased. I have my likes and dislikes, just as everyone else does. But I use closed source and open source, and I try to choose the right tool for the job at the time. My first contribution to this thread was in defence of a commercial toolchain that was dismissed because of its website, and my second was in defence of a toolchain that was dismissed simply because it is gcc.
I know it was not you that commented on the website (ImageCraft's site, not Rowley's). My point was that I think all compilers should get a fair hearing based on their merits, not prejudices.
Exactly - you are dismissing gcc simply because it is gcc.
I haven't tried any compilers for ARM, but I've seen plenty of these benchmarks around. Many of the comparisons with ARM gcc were with earlier versions of the compiler, which everyone (including the gcc developers) will tell you generated inefficient code. Comparisons of newer versions would give a different picture - I'd expect gcc to be in the same region as other optimising compilers, just as it is on many other targets. There are well-established techniques for generating good code for architectures rich in registers and with orthogonal instruction sets, and for many types of source code you will get similar generated code from any good compiler (the same applies to the avr, msp430, and ColdFire architectures with which I am familiar). Any benchmark which shows great variation is suspect.
Anyway, all benchmarks must be viewed with more than a pinch of salt. Even if the test code used bore any relationship to the code you are using in the real world, benchmarks are almost invariably arranged by someone with a point to make - compiler developers want their product to look good compared to others. Add to this that many commercial software developers have licenses that specifically limit the user's right to publish benchmark information, and published benchmarks are effectively worthless. As a potential customer, your only choices are to ask around for opinions, and download trial versions and test them out yourself.
I'm not asking you to reason with rabid fanatics - I don't see any in this thread. I'm asking you to reason with people who want to know about compiler toolchains. By dismissing gcc simply because it is gcc, and refusing to give any rational reasoning (I don't see your dislike of gcc fans as a good reason not to use the tools), you are the one leading the thread into "religion". Please, give rational technical or economic arguments for why the O/P and others should buy particular toolchains, or why they should avoid other toolchains, and leave out the biases.
What is "expensive" or not depends entirely on your requirements. I'm sure that in many cases, IAR and Keil work out as excellent value for money. But in other cases, they are very expensive. On the occasion (a fair few years ago) in which I was seriously considering IAR's AVR compiler, there is no doubt - it was extremely expensive compared to the competition, which was from ImageCraft. That was based on my requirements. I've no doubt that in other circumstances, IAR's compiler would have been the right choice.
You are right - there is no level playing field, and it would be somewhat boring if there were. gcc and high-end commercial compilers are suitable for different uses. For some uses, passing industry standard test suites is vital - for others, it is irrelevant. There are many non-technical issues surrounding buying a compiler - some people insist on having the source code, others might want a supplier that provides a warranty, some want test suite certification, others want freedom from license management issues. When these issues don't apply to you, it's easy to see them as "religion".