I think Chris really has some serious personal problems. I gather, by his admission, that he's on a c standards committee or subcommittee. Probably, if no other, then on ones related to MISRA. If so, it's emotional baggage like his that make it abundantly clear why folks supporting GCC would think twice before facing the idea of dealing with at least one such petty attitude, if not more.
Walter, I think Chris provides the answer already discussed here regarding lack of participation. With that kind of hate and spite flowing from even one member, I wouldn't expect anyone to walk into that lion's den willingly.
I'm deeply saddened by people like that and an organization that is otherwise incapable of removing him.
Well said - that post should really be the end of all the discussions about test suites (including both gcc's test suites, commercial compilers' test suites, and third-party suites like Plum Hall). It should also be the end of discussions about "a re-compilation of gcc is a different compiler and must be re-tested from scratch" and similar nonsense. It boils down to confidence factors and money - you need to invest appropriately to get the confidence levels you need for a given use.
Incidentally, I believe there *are* proven correct compilers (and proven correct execution environments) - although as you say, somewhere in the chain you lose your guarantees. They are mainly academic, however - certainly not C compilers! They also place little emphasis on generating optimal code.
Long ago, I made a brief start on doing a PhD in provably correct compiler design for parallel programming languages - that would have been fun.
Random may be a not the best choice of words. Commercial test suites do two things. 1) They are an organized series of tests designed to methodically test to a specific objective. 2) The authors of the specific test suite are not connected to the implimentors of the compiler.
GCC test suite with a couple exceptions is a regression test of some of the past detected bugs. It doesn't represent tests of a design objective.
One thing to note, however, is that people act and re-act differently in forums such as this, and in face-to-face meetings. There have been plenty of flames in this thread, and we use language and expressions that we would not use in person. Chris and I have violently disagreed here - yet I have no doubts that if we met in person, we could discuss the same issues in a perfectly friendly fashion. And I'm sure we would end up with a fair amount more agreement than we have seen here.
But in the open source world, public email-style discussions (including newsgroups, mailing lists, web forums, etc.) are by far the most important method of communication. If you can't get a good dialogue with mutual understanding going in a forum like this, you can't work well with open source developers, no matter what the committee meetings are like.
Improved relationships and greater participation between the C standards groups and open source developers (gcc in particular) would benefit both groups. Both sides need to get involved in the others work, and both sides will need a certain degree of "attitude re-adjustment". There has been some discussion here already about how gcc should have people on the standards committees, but equally the existing standards people should be looking at open source tools and how they can help.
In particular, if they are truly interested in encouraging compiler developers following the details of the standards, then they should be writing test suites themselves under an open source license. If this was started by the official standards committees, there would quickly be participation from others - to the benefit of all compiler developers, and all compiler users, open source or commercial closed source.
To see how this works, look at the www standards groups - they produce an open source reference browser and server (it doesn't matter that they are slow and ugly and few users use them - they are not aimed at general use), and open source tools for validating and checking html, xhtml, and all the other formats they control. Users can use these tools on their website, or by downloading them, or by using other software that makes use of them - the licenses let developers integrate the tools in their development tools.
These are, of course, just ideas from someone who has no idea how the C standards groups are organized and how much or how little interaction they have with gcc and open source developers, other than what I have learning in this group. I'm also skipping over details such as who might have the time, money and expertise to implement such ideas.
With his willingness to speak with such strong, profound prejudice, I certainly wouldn't be encouraged to consider the idea of working with him. Trust that others are acting out of sincerity and fairness is very, very important. It's hard to work well together without that.
Walter, I'll put this plainly. Earned public respect is important and anyone in such a position should be doing their level best to maintain a public appearance within some reasonable range of impartiality. Chris, if anything, goes out on a limb to do the very opposite; pouring disrespect and outright derision upon those who actually might even dare to consider the idea of GCC even as hobbyists, for gosh sake! And without so much as a little bit of provocation. He just jumps in out of left field to make his feelings known.
In any case, I can now feel compassion for GCC regarding your earlier point, where more curiosity and possibly shared concern once played. I'd probably get on with my life rather than spend money for a chance at this kind of insincerity.
Don't confuse difference of opinion with personal emotion. This does not portray the atmosphere of any standards committee that I have participated in. There is respect for all. They are formal debates in a relaxed atmosphere.
Unless they are explicitly allowed by law as is the case in Maryland and Virginia as well as others here in the US. I live in Maryland and have lived in Virginia and found that the legislators seem to be all too happy to allow web sites to impose their terms and conditions by posting them on the web site where *you* are responsible for checking them for changes each time you log on. That is patently absurd.
I once had a bank account with BOA and would use their web site to examine my account. It seemed that every week I had to explicitly agree to the terms and conditions. This page provided the text in a tiny window that you would have to scroll for some 10 or 15 minutes to examine ...or... it indicated that you could call them at the toll free number and request a printed copy. I called and could never get anyone to even understand what I was asking for! I ended up with some
10 or 15 copies of their "welcome" package and never got a printed copy of the web site terms and conditions. I closed my account with them.
I am not certain, but I think Maryland and Virginia have also explicitly allowed by law the type of shrinkwrap license you describe. I would love to see that challenged in court. I don't know how you can agree to a contract without being able to read it.
That's a very interesting restriction. I would love to see that one tested as well. Although, it seems to me that the easy way around that restriction is if the software owner runs the tests and someone else publishes them.
There are similar restrictions FPGA tools. Worse they seem to be able to restrict use of the compiled design that is produced from their tools. I have read about this being upheld by the courts when customers moved from FPGA to ASIC by providing a bitstream from the tools to an ASIC vendor. At least one such company was put out of business by this decision.
s
)
Talking about licenses... CodeSourcery offers these different versions. Since the code is all GPL'd, why can't the commercial users redistribute the code allowing everyone to have the more current release? Do they have some special permission from FSF to distribute other than under the GPL???
A lot of different tools have similar restrictions. For example, many tools have a limited free version with the restriction that you can't use it for commercial work.
QT have a particularly odd one for their development tools. You can get free tools (utilities and libraries) under the GPL, which obviously restricts you to developing GPL (or GPL-compatible) code - fair enough. You can also get paid-for tools and libraries, which you can use and link to code under any license you want - again, fair enough. But if you start a project using the GPL'ed tools, then buy the paid-for tools, you are not allowed to import your code and project into the paid-for tools. If you want to develop a closed-source project with QT, you must buy and use the paid-for tools from day one. I'd be very surprised to see that one stand up to legal testing (but then, IANAL, and I'm continually surprised for what passes for "justice" in some courts).
They don't release everything under the GPL - their own libraries, various debugger proxies, etc., have different licenses. For the compiler itself (and binutils), there is of course nothing to stop people redistributing the source and binaries, since it is GPL'ed. In practice, however, I don't think many would be interested - after all, you are only talking about a few months difference and people normally prefer to use "official" packages.
Standards groups are designed specifically to create standards based in the material presented. The standards groups have technical expertise in language.
Test suites promoted by standards committees would be a conflict of interest. The question would sooner or later come up as to which interpretation is the definitive standard the written one or the one codified in the test suite code.
The standards committees responsibly is to resolve interpretation differences in an unbiased way. They don't claim to have test suite or project management expertise.
The exception was Ada... the US government wanted Ad and a test suite and paid for both... as I recall the test suit cost a fortune to develop. More then Plum-Hall or Perennial cost to buy.
Some one has to pay for the development of the test suite.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Actually I agree. These forums do get a bit heated and face to face meetings less so. What I find interesting here is (some) peoples inability to separate emotion from technical debate.
We have some interesting arguments in standard meetings and then all have lunch together with no animosity. In fact one person I get on with very well with in a personal sense on one panel uses FOSS for almost everything. There are others who can't stand the sight of each other who agree technically.
At one point on WG14 some years ago AFAIR there were two members who were suing each other over things related to the standards work as companies but still working harmoniously on the panel.
There is no "both sides" there are the standard groups and people can join them. Standards groups have no need of getting involved with Open Source any more than they get involved with any other group. If the Open source people want to join the standard group they have to play by the standards group rules. Otherwise don't join. There are GCC people on standards panels.
Though in the past they Open Source has ignored standards quite a bit.
However do remember standards are there for one very important reason. To help businesses make money (followed by the law and safety where applicable :-)
It does already.
Why. They look at tools generically. Many standards panels use open source apache and wiki etc
Only if you fund it. It is far cheaper to use the Plum Hall and Perennial language test suites.... There was a standards developed test suite for Ada. I forget how much that cost to develop (over a million USD I think) . However it was only done as the US government funded it because they wanted Ada used for government military projects.
BTW The standards are not Open Source so why should the test suite be? :-) Also if developed via ISO, ANSI, MISRA, BSI, DIN etc they would not be Open Source anyway.
Not at all. WHO IS GOING TO PAY FOR IT? In Time and money. The Official standards panels are made up of people funded by their companies.
This is why there is no MISRA test suite. The amount of work, even for the comparatively small MISRA standard was far too much for the team to do. There is an Exemplar suite with a non exhaustive set of examples but that is it.
Nope they have test suites now. (Well all except most of the GCC people)
Commercial closed source have the test suites now. Why would they pay for another one? Pay as in take time (==money) or money or resources (= money) to develop such a test suite when the have an industry standard one now?
The gcc and open source is irrelevant here. They are no different to any other compiler developers as far as standards go. There are GCC developers on the standards panels now. However they only represent their own gcc development not the wider Open Source community.
The time, money and expertise are the stumbling blocks. All those with the time money and expertise already have the test suites. If the Open source community want a good test suite then make one. If it stands up then others will use it.
It is that simple
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Heard about the new GFC (GNU Financial Compilier), it does financial modelling and has both local and global consumers, product templates and pay divided distribution methods ;-)
It compares to tools costing $1 or more on the comercial scene.
Which means either you don't know everything, or our buying department has lousy negotiators. Since knowledge always is finite, I would assume the former. The compiler is from a company that does not have recommended retail prices on their website, so you don't know how much they want until you actually ask. Admitted, you get a really neat debugger with the compiler.
Unlike the compiler you hate so much, commercial compilers usually don't have publicly-readable bugtrackers, and I'd probably even violate some trade secret agreements if I told you the make & model of the compiler.
So you have to believe me that it miscompiled this simple loop for (i--; p[i] == ' '; i--); into this assembler code p0 = /* variable i */ p1 = /* variable p */ p0 = p0 + p1 r0 = [p0] /* rest of loop... */ which is obviously missing the decrement from the loop initialisation.
Chris H wrote in news: snipped-for-privacy@phaedsys.demon.co.uk:
IIRC, it stated that most of the compilers tested did not handle volatile correctly, it focussed on details of the GCC errors because the licensing terms of the commercial compilers tested did not allow them to report any details (or even identify the failing compilers).
The report then gave details on how the GCC compiler fails, along with some workarounds, which they could not provide for commercial compilers either.
When I asked one of the suppliers of a commercial compiler we have the license for about the issue, their response was that they had not checked and did not think it applied, however they were also not prepared to state that their compiler did handle the case correctly, only that they had no confirmed bugs reported.
As someone who makes a living off porting and supporting GCC, I object to this statement. From our point of view, GCC *is* a commercial compiler - we sell it and support it and make a living off it. What GCC is *not* is proprietary, please make sure you use the correct terms.
As for our discipline, bugs reported by our customers are tracked, with ongoing status updates and reports back to the customer as to the progress fixing the bug, until the customer has a new release and is satisfied that it's fixed. We have release branches for each customer's version (when custom) and release branches for each standard offering (when not). Each release is fully tested against not only our standard test suites, but also whatever test suites the customer contracts us for.
Nearly all our work is customer-driven. I rarely have time for things that "the spirit moves me" to do. Most of the people working on gcc are in similar situations, but even so, gcc itself has a bug tracker and bug reports there are taken seriously - read the mailing lists during a pre-release cycle to see how energetically bug reports are discussed and prioritized.
IAR's support team was damned over one bad customer experience, perhaps. As a support engineer I realize that every customer contact is a chance to screw up, because one bad experience *is* all it takes. I don't think this has anything to do with the quality of the product, but everything about the quality of the people backing it.
Chris H wrote in news: snipped-for-privacy@phaedsys.demon.co.uk:
snip
I strongly beg to differ on this, I recently had a problem upgrading one application to the latest version of a commercial compiler. I was using a commercial OS with source code supplied, that worked fine on the earlier compiler but seemed to have a problem with the "latest and greatist" optimizer, for one particular CPU architecture.
Since the OS vendor had not yet upgraded compilers, they could not recreate the problem, however they were happy to work with us on solving the problem.
The question was whether we were allowed to supply the OS source file in question to the compiler vendor or the details of the problem to the OS vendor. I sent an email to both requesting that we work out an acceptable solution and reseived a letter from the compiler vendor's legal representative that under the terms of the their license I could not provide any information on the performance of their product to anyone other than them. They even implied that I had violated the terms of the license by informing the OS vendor that I was having a problem with the update.
Luckily the OS vendor was prepared to purchase or upgrade to the new compiler, duplicated the problem and released a fix, but the compiler vendor was not particularly helpful.
Before you accuse me of being against commercial compilers, I have had excellent experiences with several commercial compiler vendors and have no hesiatation in recommending Cosmic C or Bytecraft among others, I have also used both commercial (ThreadX and uCOS) RTOS's as well as open soource and have been very happy with the support received.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.