Richard Stallman is responsible for the shrinking economy

Who mentioned $ ? The most expensive compiler I have is 3000GBP I can only think of two c or C++ compilers that are more expensive and they are not that much more.

Evidence please.

In message , Stefan Reuther writes

Yes.

Not random.

Yes.. It does test a SMALL random set of things. A small fraction of the tests run on most commercial compilers.

They you have no idea what you are talking about.

What "glossy brochures"

They test it. That is the problem with GCC it is not tested. You have absolutely no idea if it works or not.

It doesn't *Prove* your point. You have not tested it.

I note a recent report has found that GCC does not correctly handle volatile... How do you work around that?

Correct. However as your compiler has not been tested you have no idea if it is correct or not. Just because it appears to work in this instance is no guarantee of correct behaviour

So you say... such as? Cite some examples.

Correct but they make an attempt and end up with a completely non standard compiler that they and their team use and pass on....

Correct. Just as well.

I agree,,, go and write one.

Not my mission in life. But it certainly would be in the interest of the standards folks, it seems. That is, _iff_ there is any concern about rogue development by non-participants. If not, then I suppose it will have to come from other quarters. I would suppose they could generate an initiative in this regard. As I said, I'd contribute to it.

Like I said, it would seem to be more in line with interests by the standards committee folks. I can't speak for them, though. But certainly far less so, my own. I am just an applications type and I work with the tools I have.

Still, if there is a serious initiative proposed by a good group (and I'd consider the c standards folks a good group) I think I'd find some cash to send that way.

Just a thought.

Jon

It is an interesting paper that gives some insight into the complexities code generation testing. In this case testing for a specific fault in hundreds of test cases. Most of the failures were optimizations that conflicted with correct handling of volatile.

Regards,

-- Walter Banks Byte Craft Limited

Sadly, I had meant "not doing my argument a favor." Oh, well.

But I was very interested because of the method they used. I'd like to know more about the details.

Jon

I can't say my experience with IAR was this good. I was evaluating their software for a project, actually, I was evaluating the Atmel SAM7 part and the IAR tool came with their eval kit. As I stepped through some code, I found the debugger would get confused about the contents of various variables. When I contacted IAR about it they said that was due to problems with following the assignment of variables to registers. They didn't even hint that this would be fixed in the next release, much less an interim release.

I thought that was incredibly poor. A most basic feature of a debugger is displaying variables. I guess all optimizations could be turned off, but I'm surprised that following the assignment of registers to variables is that hard a thing to do.

Rick

It is regularly used to compile a *lot* more code than most of the niche commercial compilers, though.

In a sense, standards compliance can be a lot less important than ensuring that the existing codebase continues to run correctly.

Cheers,

In message , Jon Kirwan writes

Now there's an excuse. Yet you said above you would contribute....

No it's not. There ate two already. It is of use to some GCC folks not anyone else

Equivocation

They already have test suites. The ones you don't like.

Thanks for the compliment.

I think it was taken as read that it would be fixed. Commercial compilers tent to do that. It is the discipline they work to. Rather than fixing problems if and when the spirit moves them as per Gcc.

So IAR is dammed over one incident but GCC is fine despite many problems... Now that is religious bigotry.

Well, I am amazed that you neglect to mention that *all* the commercial compilers they tested "failed" too. Fancy that.

In fact the entire paper is bogus since they appear to misunderstand correct volatile handling themselves, as discussed here!

That is NOT true. The GCC family as a whole might be but individual versions and implementations are not. GCC is not an single entity but a huge collections of very many similar but different compilers, all differently maintained and patched

True.

Not on the volatile nut other things. Also none of the other 3 compilers tested are embedded or mainstream

Well it is not a robust paper. However it some one else brought it up and of the 13 compilers tested 11 were gcc variants.

Which, I imagine, is pretty common.

No testsuite can be said to guarantee to test ALL of the compiler's behaviour.

I suppose that enough scientific theory is available to write a proven correct compiler (which consequently doesn't require a testsuite), but you'd need a proven correct toolchain to build it. Too guarantee correct operation of this toolchain, you'd need a proven correct execution environment. But as you know, nothing in this universe is certain.

So all it comes down to is a confidence factor. An incomplete view of the product development effort that will make some random human feel good enough to release the product.

Perhaps it was legally questionable to discuss the commercial ones?...

As has been said before in this thread, many contributors to open source projects are in fact paid by large corporations to do it. A recent example is:

"14 April 2009, 18:09 Intel wants to co-develop the GCC

Three Intel employees are to contribute to the development of the GNU Compiler Collection. So far, corporate contributions to the GCC have been made by AMD and by other processor forges, while Intel focused on the development of its Intel Compiler Collection (ICC)."

It is not as if users of gcc were solely in the mercy of a bunch of hippies.

A great many clauses in the EULAs and licenses for general software are unenforceable by law, with details varying between country (and between state in the USA). It has also been established in various places that shrinkwrap licences ("by opening this package you agree to the terms detailed inside"), website licenses ("by visiting this website...."), and even click-through licenses have only limited validity, because people cannot be assumed to have read them before accepting them.

However, licenses for things like embedded compilers are treated a bit more seriously than general purpose software - they are often more like contracts. I don't know whether a "free speech" defence would stand up if you broke part of the contract preventing you publishing information about the tool. It might also depend if what you were publishing was just benchmark results, or if you were talking about bugs or vulnerabilities in the software.

gcc is far and away the easiest compiler to use for such a research paper. They can download and install half a dozen different versions, for different targets, and try them out using the same scripted test files. For commercial compilers, you need the supplier's help to get a selection of versions, and for permission to publish the results, and you can't necessarily script them so easily (or at least, you'll need to learn how to do that for the compiler in question). Thus the paper says they also tested several commercial compilers, and found that they too had faults in handling "volatile", but could not give details either due to license restrictions, or to problems testing fully.

They are the group who officially maintain several gcc targets for the FSF, including ARM, ColdFire, and (I think, but I'm not sure) PPC and MIPS. This means they work closely with the hardware suppliers as well as the FSF, and their development branches are often ahead of the FSF regarding support for newer devices. Additionally, they are heavily involved in gcc development in general (I believe the gcc 4.x release manager is from CodeSourcery, amongst other things). They give free downloads of the compilers and related tools, or you can subscribe to get slightly newer versions, better debugging tools, Eclipse integration, extra libraries, and support. You can also pay more and get higher levels of support, and they develop and sell a number of other libraries.

(I have no connection with CodeSourcery, I'm just a satisfied customer :-)

You are just being petty. I never said I'd start something like that. Different things.

No, an exacting statement that carries my intent precisely.

It's not meant for you. There's always a bad apple in every bunch.

Jon

Not as far as I know.