Joe Buck wrote:
The result is that GCC explicitly rejects something that you might have been taught in compiler class, that the standard is a contract between the compiler developer and the users and that the compiler can do anything it wants with any code that does not rigorously meet what is defined in the standard. Standard-conforming code should work, but the issue of what to do with technically incorrect, but commonly occurring code is something that we'll continue to struggle with. In some cases, serving the users might require going beyond the standard, in other cases, the cost in lost opportunities for optimization might be too high.
Indeed ... Of course it would be more controversial to depart from the standard on the basis of making the compiler more useable, and it is hard to see such a case, though I cam imagine a case where we decide the standard is plain wrong, and we won't conform to it pending it being fixed. The fundamental goal here is to generate an effectively useable compiler, conforming to the standard is a means to this end, not an end in itself. I actually think that in these cases that Joe alludes to above, concentrating *too* much on standards compliance can be the wrong emphasis, since it can lead to a position of "if it isn't in the standard, we are not interested!" which is not quite the right attitude for dealing on a case by case basis with situations where expected behavior goes beyond what is required by the standard. So putting conforming to the standards in the mission statement is not only unnecessary for me, it is probably a bad idea.