From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig AT jcb-sc.com To: mjbedy AT mtu.edu Cc: craig AT jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 16 Sep 1999 02:19:00 -0000 Message-id: <19990916085308.19323.qmail@deer> References: X-SW-Source: 1999-09/msg00689.html >> If it's not a feature, then backwards compatibility is not an issue. > > I believe the above sentence is untrue. The behaviour of the compiler >has changed, reguardless of any lables we might throw on the situation. I already addressed that: the behavior of the compiler *always* changes upon installing a new release, else there's no point in installing, or even creating, it. (Not quite 100% true, but let's say 99.9% of the time, that's all true.) If you don't want the behavior of your program changing due to a change in the compiler and/or version used to build it, then it is up to you, the author of that program, to specify exactly which compiler/version is to be used. > However, this change is one that can affect the correctness of the users >code. No. It is correct to say "this change is one that can expose the incorrectness of the user's code". And that can be said of almost *any* change made to the code-generation facility of a compiler. >If we can warn the user by writing a reasonable amount of code then >it seems to be the "nice" thing to do. Even if we can't catch all >occurances (as is mentioned earlier in this thread), the ones we can catch >may be quite a help to the user. I agree with that. > The assembly thing (which I don't 100% understand - I have no need to >use it so I don't completely know the issue) is a good example, I think. It's simple. When you do "gcc foo.c", you get an a.out executable, but that process, behind your back so to speak, generates, among other things, an assembly (.s) file containing the low-level machine codes the compiler picked to implement the code in foo.c as mnemonic instructions. Those instructions represent the closest thing the software industry has to a widely understood "fix" of how the code in foo.c is actually implemented by the compiler, e.g. given "i = j++ + k++;", whether j or k gets incremented first. If you, as a programmer, wish the behavior of your *program* to not change, you can, as I said, simply designate a *particular* compiler and version combination to use (for a particular platform, say). And if you don't want to require people to have that particular combination on their machines to build your program, but want them to have the source code at some level, then provide them the assembly (.s) file along with your source code, and instruct the user (via Makefile, perhaps) to "compile" (really, assemble) *that* instead of the .c. >The behavior of the compiler was deliberatly changed. I don't care about >what the documentation said, or who was broken before, or any of that. The >fact is that code that used to work began (as I understand it) to fail >silently. This is bad, even if it IS in an FAQ somewhere. Now a warning >has been added. So the change, which is a positive one, gets to stay, but >the user gets fair warning from the compiler. The *developer* of the *code* already got fair warning, or else is a dunce who shouldn't be allowed anywhere near a computer, especially not as a programmer. Only people who understand, or at least accept, the fact that re-compiling their code can legitimately change the apparent behavior of their code should be allowed to represent themselves as programmers in languages requiring compilation (or even interpretation). Otherwise they should restrict themselves to programming in assembly language. And to a very simple machine model at that. I suggest the PDP-8. If they can't fit their programs into 32K 12-bit words in PDP-8 assembly code, they aren't real programmers anyway. Now, what *users* expect is a whole 'nother can of worms. If users need fair warning that a program might not work because they use a different compiler on it, then that warning must come from the developers of that *program*, not the compiler. > Now imagine that this export thing, instead of spewing an error, >silently went on to miscompile the code. Well-designed languages are that way to the extent that they make it easy for compilers and interpreters that implement them reject, or at least warn about, erroneous constructs that programmers might easily enter, and that means those rejections and warnings are seen by the *programmers*, not the *users* of the program. That's the problem with this whole notion that it is up to GCC to serve as a sort of free-software installation tool. It is the *programmer*, not the installer, that needs to see the warnings. GCC can't do that as a free-software installation tool. It can do that, in some cases, when properly used as a *compiler*. Still, since C is not exactly a well-designed language, it is not easy to write static-code-checkers (a la the lint-like facility of GCC) to find all the problems typically committed by programmers. > It is unfortuante that it is immpossile to spew a warning on every >instance of the alias problem, but I think it is necessary to provide a >warning when we can do so with a minimum of effort. I think everyone agrees to that. What is not widely appreciated or understood is that this warning *probably* will, itself, "change" across versions/releases of GCC, and that programmers and users will be as upset about those changes in *this* case as in the case of alias analysis becoming the default. Am I wrong? Well, after *tons* of exactly correct pointing out of the issues, correcting *many* people on this list, as done by people such as myself and Mark Mitchell, can anyone point to a *single* example of anyone admitting they had been wrong and now understood that they should not expect a compiler to never change the behavior of their program, especially if it invokes undefined behavior according to the pertinent language standard? So I can see why a few people might think even a warning is likely to constitute just another new minefield for GCC developers to have to march through in another year or two. That's why I strongly resist a warning implemented by having to change code-generation strategies. If the new strategy is preferable absent any difference in warnings, fine; then, presumably, the new warning *can* be easily added and maintained. But anyone who thinks GCC developers can avoid this whole problem (of huge amounts of argument about how GCC is "breaking programs") by making it warn about this construct is, frankly, deluding themselves. >> And there is no current silent corruption that is default in GCC >> as pertains this thread. If you believe that, you were misinformed, >> and should abstain from repeating this misinformation in any other >> forum in the future. > > ? Please explain? I thought the whole point of this thread is the >effect that alias analysis has had on Linux, god knows what else, etc. I >though the effect was "incorrect" code (code that does not run as >intended) generated by gcc since it assumed that ANSI rules were being >followed by the source. Maybe silent corruption was a bad choice of words, >and "incorrect" code (including the quotes) is a better one. See above. >> The whole problem here is simply one of miseducation, or ignorance, >> on the part of people who think they know what GCC is. We need not >> change one line of code to fix *that* problem, and if we don't >> fix that problem, rewriting GCC from scratch will not fix it either. >> Certainly changing a few lines will have no worthwhile overall effect. >> > > Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler >maintain by the GCC team, which is an absolutly essentail part of the free >software movement. I'm not sure what this has to do with the discussion at >hand. Some people think GCC is a hand-holding catch-all for installing free software from source, regardless of the correctness of that source code (as long as it might have seemed to work on some old version of some C compiler somewhere), or some approximation thereof. That's why they think that GCC is now breaking programs by defaulting to employing its alias analysis. People who don't clearly understand the proper roles of various computer programs, programmers, and end users will *never* be able to produce well-engineered products. tq vm, (burley) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: mjbedy@mtu.edu Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990916085308.19323.qmail@deer> References: X-SW-Source: 1999-09n/msg00689.html Message-ID: <19990930180200.6mN-eHoDr51hgEuV88JZSiC6ckAGD62x48mtWA6AuhY@z> >> If it's not a feature, then backwards compatibility is not an issue. > > I believe the above sentence is untrue. The behaviour of the compiler >has changed, reguardless of any lables we might throw on the situation. I already addressed that: the behavior of the compiler *always* changes upon installing a new release, else there's no point in installing, or even creating, it. (Not quite 100% true, but let's say 99.9% of the time, that's all true.) If you don't want the behavior of your program changing due to a change in the compiler and/or version used to build it, then it is up to you, the author of that program, to specify exactly which compiler/version is to be used. > However, this change is one that can affect the correctness of the users >code. No. It is correct to say "this change is one that can expose the incorrectness of the user's code". And that can be said of almost *any* change made to the code-generation facility of a compiler. >If we can warn the user by writing a reasonable amount of code then >it seems to be the "nice" thing to do. Even if we can't catch all >occurances (as is mentioned earlier in this thread), the ones we can catch >may be quite a help to the user. I agree with that. > The assembly thing (which I don't 100% understand - I have no need to >use it so I don't completely know the issue) is a good example, I think. It's simple. When you do "gcc foo.c", you get an a.out executable, but that process, behind your back so to speak, generates, among other things, an assembly (.s) file containing the low-level machine codes the compiler picked to implement the code in foo.c as mnemonic instructions. Those instructions represent the closest thing the software industry has to a widely understood "fix" of how the code in foo.c is actually implemented by the compiler, e.g. given "i = j++ + k++;", whether j or k gets incremented first. If you, as a programmer, wish the behavior of your *program* to not change, you can, as I said, simply designate a *particular* compiler and version combination to use (for a particular platform, say). And if you don't want to require people to have that particular combination on their machines to build your program, but want them to have the source code at some level, then provide them the assembly (.s) file along with your source code, and instruct the user (via Makefile, perhaps) to "compile" (really, assemble) *that* instead of the .c. >The behavior of the compiler was deliberatly changed. I don't care about >what the documentation said, or who was broken before, or any of that. The >fact is that code that used to work began (as I understand it) to fail >silently. This is bad, even if it IS in an FAQ somewhere. Now a warning >has been added. So the change, which is a positive one, gets to stay, but >the user gets fair warning from the compiler. The *developer* of the *code* already got fair warning, or else is a dunce who shouldn't be allowed anywhere near a computer, especially not as a programmer. Only people who understand, or at least accept, the fact that re-compiling their code can legitimately change the apparent behavior of their code should be allowed to represent themselves as programmers in languages requiring compilation (or even interpretation). Otherwise they should restrict themselves to programming in assembly language. And to a very simple machine model at that. I suggest the PDP-8. If they can't fit their programs into 32K 12-bit words in PDP-8 assembly code, they aren't real programmers anyway. Now, what *users* expect is a whole 'nother can of worms. If users need fair warning that a program might not work because they use a different compiler on it, then that warning must come from the developers of that *program*, not the compiler. > Now imagine that this export thing, instead of spewing an error, >silently went on to miscompile the code. Well-designed languages are that way to the extent that they make it easy for compilers and interpreters that implement them reject, or at least warn about, erroneous constructs that programmers might easily enter, and that means those rejections and warnings are seen by the *programmers*, not the *users* of the program. That's the problem with this whole notion that it is up to GCC to serve as a sort of free-software installation tool. It is the *programmer*, not the installer, that needs to see the warnings. GCC can't do that as a free-software installation tool. It can do that, in some cases, when properly used as a *compiler*. Still, since C is not exactly a well-designed language, it is not easy to write static-code-checkers (a la the lint-like facility of GCC) to find all the problems typically committed by programmers. > It is unfortuante that it is immpossile to spew a warning on every >instance of the alias problem, but I think it is necessary to provide a >warning when we can do so with a minimum of effort. I think everyone agrees to that. What is not widely appreciated or understood is that this warning *probably* will, itself, "change" across versions/releases of GCC, and that programmers and users will be as upset about those changes in *this* case as in the case of alias analysis becoming the default. Am I wrong? Well, after *tons* of exactly correct pointing out of the issues, correcting *many* people on this list, as done by people such as myself and Mark Mitchell, can anyone point to a *single* example of anyone admitting they had been wrong and now understood that they should not expect a compiler to never change the behavior of their program, especially if it invokes undefined behavior according to the pertinent language standard? So I can see why a few people might think even a warning is likely to constitute just another new minefield for GCC developers to have to march through in another year or two. That's why I strongly resist a warning implemented by having to change code-generation strategies. If the new strategy is preferable absent any difference in warnings, fine; then, presumably, the new warning *can* be easily added and maintained. But anyone who thinks GCC developers can avoid this whole problem (of huge amounts of argument about how GCC is "breaking programs") by making it warn about this construct is, frankly, deluding themselves. >> And there is no current silent corruption that is default in GCC >> as pertains this thread. If you believe that, you were misinformed, >> and should abstain from repeating this misinformation in any other >> forum in the future. > > ? Please explain? I thought the whole point of this thread is the >effect that alias analysis has had on Linux, god knows what else, etc. I >though the effect was "incorrect" code (code that does not run as >intended) generated by gcc since it assumed that ANSI rules were being >followed by the source. Maybe silent corruption was a bad choice of words, >and "incorrect" code (including the quotes) is a better one. See above. >> The whole problem here is simply one of miseducation, or ignorance, >> on the part of people who think they know what GCC is. We need not >> change one line of code to fix *that* problem, and if we don't >> fix that problem, rewriting GCC from scratch will not fix it either. >> Certainly changing a few lines will have no worthwhile overall effect. >> > > Ok. What is GCC? Gcc to me is the free/opensource/whatever compiler >maintain by the GCC team, which is an absolutly essentail part of the free >software movement. I'm not sure what this has to do with the discussion at >hand. Some people think GCC is a hand-holding catch-all for installing free software from source, regardless of the correctness of that source code (as long as it might have seemed to work on some old version of some C compiler somewhere), or some approximation thereof. That's why they think that GCC is now breaking programs by defaulting to employing its alias analysis. People who don't clearly understand the proper roles of various computer programs, programmers, and end users will *never* be able to produce well-engineered products. tq vm, (burley)