From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: jbuck@synopsys.COM Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Fri, 10 Sep 1999 08:43:00 -0000 Message-id: <19990910152622.9143.qmail@deer> References: <199909100708.AAA00030@atrus.synopsys.com> X-SW-Source: 1999-09/msg00413.html If a warning is simple enough to add that it takes only a few lines occurs in an obvious place, and doesn't experience a change in its "envelope" due to reasonable changes in how a compiler internally represents things, I'm all for it in a product like GCC. That's not my impression as to how *this* proposed warning is likely to be implemented. That's why I'm not in favor of it, along with the fact that this issue is already taking up far more valuable time on these lists than it *ever* deserved. [Joe wrote:] >Exactly; post violations I've seen are of that type. I can't aspire to >the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps >missing this point: a whole lot of the errors we've seen are of this >extremely simple form, with the entire error appearing in two or three >adjacent lines of code. We know the exact offsets of each address and >can clearly see that they collide. Let me see if I can explain my concerns here. If we introduce the proposed new warning in GCC, it will require not only some significant changes to implement, it *will* require extra work to maintain. Forever. Until the end of time. That's because the mere *apparent* promise that GCC will warn about suspicious constructs will be enough to persuade too many people that they don't need to audit their code, line by line, and fix the problem. [Joe later wrote:] >My intent, which may be different from RMS's intent, is to help users >get rid of this variety of invalid code, not to perpetuate it. I agree 100%. I believe this proposed warning will be interpreted by much of the user base as a reliable indicator of when to turn off alias analysis rather than of when to fix their code, based on how this issue has been treated in these discussions. So those people will rely on GCC holding their hands. Most of the time it might be correct. Too often, it will be wrong. We will blamed when it is, just as we've been blamed *already* for providing a *correct* compiler with a *simple* workaround for buggy code. Remember, some of you have already been seriously considering having the mere *warning* trigger a *different* code-generation strategy. Why? I think the answer is pretty clear -- it's because you already know, deep, down inside, that the real agenda here is to make it easy for people who think GCC really *should* support their alias-concern-free variant of the C language to continue to write code *their* way. Then they'll just ignore, or filter out, the warnings. (If the FAQ could say "don't do that", then it could just as well say "use -fno-strict-aliasing". Hey!! It already does! Then why are we having this discussion, if we are going to assume people will read the docs?) If that's not the case, then please end all discussion of the warning turning off aliasing. That's no more sensible than having the uninitialized-variable warning triggering the automatic bzero-ing of the stack frame upon entry to every procedure, along with all sorts of other "friendly" things for warnings to do. Now, I already *know* all the counterarguments to this concern. But every one of them can be applied to the *current* situation, where we have *no* warnings, -fstrict-aliasing is the default, and users have the -fno-strict-aliasing option: - "We can tell people not to rely on the warnings, or lack thereof, as any sort of substitute for fixing their code." Oh sure, tell them to read the docs. Sorry: that didn't work in the first place to get them to write ANSI/ISO-conforming code *or* to get them to use -fno-strict-aliasing. If you think they'll go away just because a new warning appears, please cite your evidence for that tactic working under similar circumstances -- I'd love to see it. (Having worked on g77, which has a *far* more forgiving audience, in this sense, than gcc, I know firsthand how new warnings are received, no matter how well they're documented. They're no panacea. And I suggest the g77 warnings I'm thinking of are, and have generally been, *vastly* better documented than GCC warnings -- so if you think you're going to avoid a substantial number of complaints and real problems with this warning, you'll have to document it better than g77 documents any of *its* warnings, IMO.) - "It's important to catch *all* the possible problems somehow, so as to avoid generating bad code." Not only is the warning idea going to *fail* at that, there's *already* -fno-strict-aliasing. That is the most reliable method we're going to ever offer. Period. - "We're just trying to address certain common cases that occur within only a few lines of code, not get at all the problems at once." A much more reasonable stance. I suggest someone write a few lines of Perl, Scheme, or some such thing to do the job. Please leave it out of GCC internals, though it could be shipped with GCC. - "But people expect GCC to do all these things for them." It can't and won't, so we should pick and choose the things it'll do best. That Perl/Scheme script? Using the time/energy spent conducting pro-munging-GCC campaigns on these lists, I'm sure a "clever programmer" or two could not only have written it, but tested it *and* distributed it, perhaps two or three versions by now. What the C community needs is a tool to find this particularly gnarly problem. It should view it as a use-once-and-fix-thereby tool. Fixing this problem is like fixing the Y2K problem. Do it once, and do it right. Putting the same functionality in GCC suggests more of an ad-hoc approach to deciding whether to tolerate, fix, or ignore the problem. And the users who supposedly need this solution *now* could get it *now* if you'd (whoever you are) just go and write it, distribute it, and not make them wait (even longer) for GCC 3.0. (Longer because of the time it'll take to add, document, and write test cases for this new warning. And what happens when, one month before scheduled release, someone notices that the warning doesn't work right on *one* platform, like the uninitialized-variable warning awhile ago on Alphas? Do we delay the release to fix this warning, which is supposedly so crucial we've spent all this time discussing and installing it, or blow off the importance of helping those poor, confused C programmers on a major platform?) - "It's much easier to change GCC to warn about this than to write a new script, especially when it comes to certain cases." I suggest that if a simple script can't catch the problem, a GCC warning, even if it worked, wouldn't help users catch the problem any more than they're helped now using -fno-strict-analysis. (That is, such users have *already* claimed they're not going to fix code where the problem is strewn throughout. I'm thinking of Linux here. And whatever the Linux cognescenti decide, many thousands of programmers will surely do as well. In that sense, Linus and David Miller have given us tremendously valuable input -- a preview of what, say, 1000 programmers will be screaming at us about one year after Merced, or McKinley, comes out.) But, if you like, snarf a copy of GCC, strip out all the code generation, and add the patch you think is so easy to warn about the problem. Make it a separate product, on its own release schedule. Same reasons as above. In other words, have GCC distribute not only cc1, protoize, and unprotoize, but findalias as well. - "But the proposed warning won't make GCC much more complex." Perhaps not, but every little addition like this requires all *future* maintainers of GCC to cope with that much more state, that much more complexity, and, most difficult for new, enthusiastic developers to cope with, more "quiet expectation" that the "envelope" of the warning (the circumstances under which it is and is not issued) will never change or, at least, will only "get better". With *this* proposed warning, I think that's going to be particularly challenging, based on the discussions of the technical aspects of it. The wording Joe used earlier, "the mode of treating the user like an opponent", bothered me because it implied that any refusal to add new "features" constituted opposing users. That is probably not what Joe intended, but, let me say, the willingness to add any new feature asked for by users *can* constitute opposing the ability of your "e-descendants" to continue to maintain the product as a going concern. So, while a warning (that has no effect on code generation) *might* be a good idea, I tend to think that, in this case, it is not, based on a rather quick reading of the original (recent) proposal. As back-up to my positions, I suggest readers review archives (wish they could do so of the gcc2 postings I remember from years back) vis-a-vis complaints and hassles when much simpler (conceptually) warnings didn't behave as expected, such as uninitialized-variable warnings; and vis-a-vis claims about how GCC should cater to "clever programmers" (their own words) by providing essentially endless, detailed control over every aspect of code generation, even if doing so is at the expense of delivering a robust, high-performance, predictable compiler for "non-clever" programmers who actually follow the standards, read the documentation, and rely on much more than "well, it always worked that way before" to justify their requests. In the end, it's a question of what kind of users we want to cater to. I've found it much easier to cater to people who "read the directions", so to speak, than those who ride by the seat of their pants. YMMV, but it should be easy to see why catering directly to the former allows the latter to continue to operate however they like -- catering to the latter makes the product worse for direction-followers and only encourages the direction-ignorers to take even more risks. (Which was the point I was trying to make with my previous post containing the shell script -- exactly the sort of thing a "clever programmer" would invent *and* expect to always work.) tq vm, (burley) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: jbuck@synopsys.COM Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990910152622.9143.qmail@deer> References: <199909100708.AAA00030@atrus.synopsys.com> X-SW-Source: 1999-09n/msg00413.html Message-ID: <19990930180200.esZSlUZ7-KepztlmrhNJv5mkKdotlQu4Dt6EVrp9KLU@z> If a warning is simple enough to add that it takes only a few lines occurs in an obvious place, and doesn't experience a change in its "envelope" due to reasonable changes in how a compiler internally represents things, I'm all for it in a product like GCC. That's not my impression as to how *this* proposed warning is likely to be implemented. That's why I'm not in favor of it, along with the fact that this issue is already taking up far more valuable time on these lists than it *ever* deserved. [Joe wrote:] >Exactly; post violations I've seen are of that type. I can't aspire to >the same level of guru-hood as Jeff, Mark, and Craig, but they are perhaps >missing this point: a whole lot of the errors we've seen are of this >extremely simple form, with the entire error appearing in two or three >adjacent lines of code. We know the exact offsets of each address and >can clearly see that they collide. Let me see if I can explain my concerns here. If we introduce the proposed new warning in GCC, it will require not only some significant changes to implement, it *will* require extra work to maintain. Forever. Until the end of time. That's because the mere *apparent* promise that GCC will warn about suspicious constructs will be enough to persuade too many people that they don't need to audit their code, line by line, and fix the problem. [Joe later wrote:] >My intent, which may be different from RMS's intent, is to help users >get rid of this variety of invalid code, not to perpetuate it. I agree 100%. I believe this proposed warning will be interpreted by much of the user base as a reliable indicator of when to turn off alias analysis rather than of when to fix their code, based on how this issue has been treated in these discussions. So those people will rely on GCC holding their hands. Most of the time it might be correct. Too often, it will be wrong. We will blamed when it is, just as we've been blamed *already* for providing a *correct* compiler with a *simple* workaround for buggy code. Remember, some of you have already been seriously considering having the mere *warning* trigger a *different* code-generation strategy. Why? I think the answer is pretty clear -- it's because you already know, deep, down inside, that the real agenda here is to make it easy for people who think GCC really *should* support their alias-concern-free variant of the C language to continue to write code *their* way. Then they'll just ignore, or filter out, the warnings. (If the FAQ could say "don't do that", then it could just as well say "use -fno-strict-aliasing". Hey!! It already does! Then why are we having this discussion, if we are going to assume people will read the docs?) If that's not the case, then please end all discussion of the warning turning off aliasing. That's no more sensible than having the uninitialized-variable warning triggering the automatic bzero-ing of the stack frame upon entry to every procedure, along with all sorts of other "friendly" things for warnings to do. Now, I already *know* all the counterarguments to this concern. But every one of them can be applied to the *current* situation, where we have *no* warnings, -fstrict-aliasing is the default, and users have the -fno-strict-aliasing option: - "We can tell people not to rely on the warnings, or lack thereof, as any sort of substitute for fixing their code." Oh sure, tell them to read the docs. Sorry: that didn't work in the first place to get them to write ANSI/ISO-conforming code *or* to get them to use -fno-strict-aliasing. If you think they'll go away just because a new warning appears, please cite your evidence for that tactic working under similar circumstances -- I'd love to see it. (Having worked on g77, which has a *far* more forgiving audience, in this sense, than gcc, I know firsthand how new warnings are received, no matter how well they're documented. They're no panacea. And I suggest the g77 warnings I'm thinking of are, and have generally been, *vastly* better documented than GCC warnings -- so if you think you're going to avoid a substantial number of complaints and real problems with this warning, you'll have to document it better than g77 documents any of *its* warnings, IMO.) - "It's important to catch *all* the possible problems somehow, so as to avoid generating bad code." Not only is the warning idea going to *fail* at that, there's *already* -fno-strict-aliasing. That is the most reliable method we're going to ever offer. Period. - "We're just trying to address certain common cases that occur within only a few lines of code, not get at all the problems at once." A much more reasonable stance. I suggest someone write a few lines of Perl, Scheme, or some such thing to do the job. Please leave it out of GCC internals, though it could be shipped with GCC. - "But people expect GCC to do all these things for them." It can't and won't, so we should pick and choose the things it'll do best. That Perl/Scheme script? Using the time/energy spent conducting pro-munging-GCC campaigns on these lists, I'm sure a "clever programmer" or two could not only have written it, but tested it *and* distributed it, perhaps two or three versions by now. What the C community needs is a tool to find this particularly gnarly problem. It should view it as a use-once-and-fix-thereby tool. Fixing this problem is like fixing the Y2K problem. Do it once, and do it right. Putting the same functionality in GCC suggests more of an ad-hoc approach to deciding whether to tolerate, fix, or ignore the problem. And the users who supposedly need this solution *now* could get it *now* if you'd (whoever you are) just go and write it, distribute it, and not make them wait (even longer) for GCC 3.0. (Longer because of the time it'll take to add, document, and write test cases for this new warning. And what happens when, one month before scheduled release, someone notices that the warning doesn't work right on *one* platform, like the uninitialized-variable warning awhile ago on Alphas? Do we delay the release to fix this warning, which is supposedly so crucial we've spent all this time discussing and installing it, or blow off the importance of helping those poor, confused C programmers on a major platform?) - "It's much easier to change GCC to warn about this than to write a new script, especially when it comes to certain cases." I suggest that if a simple script can't catch the problem, a GCC warning, even if it worked, wouldn't help users catch the problem any more than they're helped now using -fno-strict-analysis. (That is, such users have *already* claimed they're not going to fix code where the problem is strewn throughout. I'm thinking of Linux here. And whatever the Linux cognescenti decide, many thousands of programmers will surely do as well. In that sense, Linus and David Miller have given us tremendously valuable input -- a preview of what, say, 1000 programmers will be screaming at us about one year after Merced, or McKinley, comes out.) But, if you like, snarf a copy of GCC, strip out all the code generation, and add the patch you think is so easy to warn about the problem. Make it a separate product, on its own release schedule. Same reasons as above. In other words, have GCC distribute not only cc1, protoize, and unprotoize, but findalias as well. - "But the proposed warning won't make GCC much more complex." Perhaps not, but every little addition like this requires all *future* maintainers of GCC to cope with that much more state, that much more complexity, and, most difficult for new, enthusiastic developers to cope with, more "quiet expectation" that the "envelope" of the warning (the circumstances under which it is and is not issued) will never change or, at least, will only "get better". With *this* proposed warning, I think that's going to be particularly challenging, based on the discussions of the technical aspects of it. The wording Joe used earlier, "the mode of treating the user like an opponent", bothered me because it implied that any refusal to add new "features" constituted opposing users. That is probably not what Joe intended, but, let me say, the willingness to add any new feature asked for by users *can* constitute opposing the ability of your "e-descendants" to continue to maintain the product as a going concern. So, while a warning (that has no effect on code generation) *might* be a good idea, I tend to think that, in this case, it is not, based on a rather quick reading of the original (recent) proposal. As back-up to my positions, I suggest readers review archives (wish they could do so of the gcc2 postings I remember from years back) vis-a-vis complaints and hassles when much simpler (conceptually) warnings didn't behave as expected, such as uninitialized-variable warnings; and vis-a-vis claims about how GCC should cater to "clever programmers" (their own words) by providing essentially endless, detailed control over every aspect of code generation, even if doing so is at the expense of delivering a robust, high-performance, predictable compiler for "non-clever" programmers who actually follow the standards, read the documentation, and rely on much more than "well, it always worked that way before" to justify their requests. In the end, it's a question of what kind of users we want to cater to. I've found it much easier to cater to people who "read the directions", so to speak, than those who ride by the seat of their pants. YMMV, but it should be easy to see why catering directly to the former allows the latter to continue to operate however they like -- catering to the latter makes the product worse for direction-followers and only encourages the direction-ignorers to take even more risks. (Which was the point I was trying to make with my previous post containing the shell script -- exactly the sort of thing a "clever programmer" would invent *and* expect to always work.) tq vm, (burley)