From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: craig@jcb-sc.com Cc: jbuck@synopsys.COM, mrs@wrs.com, gcc@gcc.gnu.org, craig@jcb-sc.com Subject: Re: type based aliasing again Date: Sun, 12 Sep 1999 00:51:00 -0000 Message-id: <199909120800.EAA04250@psilocin.gnu.org> References: <199909100708.AAA00030@atrus.synopsys.com> <19990910152622.9143.qmail@deer> <199909110725.DAA03149@psilocin.gnu.org> <19990911104435.13384.qmail@deer> X-SW-Source: 1999-09/msg00459.html >I say we should keep user code found in real programs working, as long >as that is easy to do. Sometimes it is necessary or important to >break code people use, and then it's worth doing so. But when we have >an easy and painless way to keep certain code working, then breaking >it is not necessary or important, so we shouldn't. I don't really disagree with this. The "easy to do" part is important. It is beyond important, it is the point of the idea. That is where this alternative differs from the others that people have been considering. I want to emphasize that "easy to do", in RMS's terms, means to me that the compiler should *itself* never make this assessment. It should be made only by compiler writers, based on a cursory examination. That's what I have in mind, too. The thing that might or might not be "easy to do" is the *change* in GCC, that people could write. It is so difficult to explain this so users don't misunderstand this as some sort of promise for a long-term accommodation of certain sorts of broken code, that I don't suggest we do it in anything that appears to be user documentation. That's what I have in mind, too. It looks like people have until now rejected consideration of all but these two alternatives: 1. Document these cases as a feature, and keep it working come hell or high water. 2. Make absolutely no effort to keep these cases working. These are two extremes in a continuum. If we really had only these two choices, #2 would be better, for the reasons others have given. But if we admit the intermediate possibilities, we can usually find one that is better than either extreme: 3. Make a little effort to keep these cases working today. Actually, in some sense #2 is not the ultimate extreme. We could go even further: 4. Make damned sure these cases will not behave as expected. This would be a subcase of the -fconfound-me option you proposed. I mention it to show how #2 is different from this--and what that implies. Some people argue that users will "get the wrong ideas" if any of these cases do work. Well, if that is possible, it is happening now, because some of these cases do work. With -O0, they all work. Unless we do #4, some of them will always work. I'm not the GCC maintainer any more, and I don't have time to get involved in more than a handful of the technical decisions about GCC, even if I wanted to. This particular issue is important because many users are unhappy with it. But there's a bigger question at stake: what is the right basis for making such decisions about GCC? That question is crucial for this issue now, and will be crucial for other issues in the future. To do a good job, we must consider option #3. On some issues, there will be a good way to use option #3; on others, there won't be. But if we don't use it when there is a way, we will make GCC a harsh compiler. Please, always consider option #3. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Stallman To: craig@jcb-sc.com Cc: jbuck@synopsys.COM, mrs@wrs.com, gcc@gcc.gnu.org, craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909120800.EAA04250@psilocin.gnu.org> References: <199909100708.AAA00030@atrus.synopsys.com> <19990910152622.9143.qmail@deer> <199909110725.DAA03149@psilocin.gnu.org> <19990911104435.13384.qmail@deer> X-SW-Source: 1999-09n/msg00459.html Message-ID: <19990930180200.qmJ21Z8m6A2YcTRH4DI2__r2oYFf6OmnXLUotRNCNsk@z> >I say we should keep user code found in real programs working, as long >as that is easy to do. Sometimes it is necessary or important to >break code people use, and then it's worth doing so. But when we have >an easy and painless way to keep certain code working, then breaking >it is not necessary or important, so we shouldn't. I don't really disagree with this. The "easy to do" part is important. It is beyond important, it is the point of the idea. That is where this alternative differs from the others that people have been considering. I want to emphasize that "easy to do", in RMS's terms, means to me that the compiler should *itself* never make this assessment. It should be made only by compiler writers, based on a cursory examination. That's what I have in mind, too. The thing that might or might not be "easy to do" is the *change* in GCC, that people could write. It is so difficult to explain this so users don't misunderstand this as some sort of promise for a long-term accommodation of certain sorts of broken code, that I don't suggest we do it in anything that appears to be user documentation. That's what I have in mind, too. It looks like people have until now rejected consideration of all but these two alternatives: 1. Document these cases as a feature, and keep it working come hell or high water. 2. Make absolutely no effort to keep these cases working. These are two extremes in a continuum. If we really had only these two choices, #2 would be better, for the reasons others have given. But if we admit the intermediate possibilities, we can usually find one that is better than either extreme: 3. Make a little effort to keep these cases working today. Actually, in some sense #2 is not the ultimate extreme. We could go even further: 4. Make damned sure these cases will not behave as expected. This would be a subcase of the -fconfound-me option you proposed. I mention it to show how #2 is different from this--and what that implies. Some people argue that users will "get the wrong ideas" if any of these cases do work. Well, if that is possible, it is happening now, because some of these cases do work. With -O0, they all work. Unless we do #4, some of them will always work. I'm not the GCC maintainer any more, and I don't have time to get involved in more than a handful of the technical decisions about GCC, even if I wanted to. This particular issue is important because many users are unhappy with it. But there's a bigger question at stake: what is the right basis for making such decisions about GCC? That question is crucial for this issue now, and will be crucial for other issues in the future. To do a good job, we must consider option #3. On some issues, there will be a good way to use option #3; on others, there won't be. But if we don't use it when there is a way, we will make GCC a harsh compiler. Please, always consider option #3.