From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: rms@gnu.org Cc: jbuck@synopsys.COM, gcc@gcc.gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990910000721D.mitchell@codesourcery.com> References: <199909090109.SAA28465@atrus.synopsys.com> <19990908184709F.mitchell@codesourcery.com> <199909100634.CAA01812@psilocin.gnu.org> X-SW-Source: 1999-09n/msg00402.html Message-ID: <19990930180200.0xoYfGnZ4dBW8gUvNfsnzJpr29siMSAFN5ialoVvA2Y@z> >>>>> "Richard" == Richard Stallman writes: Richard> The goal of trying to avoid it is unrealistic and Richard> misguided; it can't be done. So this cannot be a valid Richard> reason to reject a change. You are right that it cannot be done. However, it is good to strive for things which are good, even if they are impossible to achieve. (For example, we strive to make GCC a bug-free compiler, even though that will never happen.) You've chosen to respond to a long conversation all at once. Let me try to sum up the current state, as I see it: o We all agree that if it is technically feasible to warn about invalid code, we should. It will be difficult to produce a useful warning, but, if someone can figure out how, I don't think there's any debate that this is worthwhile. Even if there are some false positives. o Code which will "work" with the proposed change may (will) break with future releases of GCC. This will lead to worse headaches for users than the simple rule: don't treat memory as having multiple types, or else use -fno-strict-aliasing. Users will be particularly at risk because when the behavior gets worse (from their point of view) warnings will go away, not appear. Mark> The compiler should continue to aggressively break Mark> code that misbehaves in this way. Richard> This proposes to break users' code, just to bully them Richard> into changing it. That is a callous and harsh attitude Richard> towards the users of GCC. No wonder users are angry. Richard> They know that the problems are not due to necessity, but Richard> due to callous disregard for them. That is a harsh statement, which I take personally. I have volunteered a lot of time and effort responding directly to users needs and wishes. You should not read intent into statements, without asking the speaker to clarify first. Please treat me with the same respect I have shown Joe Buck and others who have raised this issue, including those who have called me nasty names in the past. There is no way that we can guarantee the long-term viability of this variety of invalid code. Seemingly minor changes to the compiler will change the set of programs which "work", with your proposal. Other compilers are already doing these optimizations. Thus, portable code, including most GNU project code, simply must not contain these invalid constructs. I firmly belive that it is better for users to have a simple, easy to follow guideline, than a shifting, confusing one. Perhaps that is where you and I differ, but it does not imply that either of us have disregard for users. I have spent a good deal of time considering not only this proposal, but many others that have appeared on this list. Thus, I have *reluctantly* concluded that there is no graceful failure mode. Of course, I am willing to be persuaded. There is a lot of code out there that assumes bitfields are unsigned. That's not always true; such code breaks in those situations. Users must know, when compiling such code, that they must specify -funsigned-bitfields. This situation is similar: users must know that they must specify -fno-strict-aliasing when compiling these programs. If we can figure out how to do the warning, we should; that's more than we can offer in many other similar cases (like in the bitfield case). -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com