From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: jbuck@synopsys.COM Cc: gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Wed, 08 Sep 1999 18:43:00 -0000 Message-id: <19990908184709F.mitchell@codesourcery.com> References: <199909090109.SAA28465@atrus.synopsys.com> X-SW-Source: 1999-09/msg00317.html >>>>> "Joe" == Joe Buck writes: Joe> The change is simply to postpone the type-based check until Joe> after the other analysis is done. If we detect that the Joe> references collide, but the types say that we can assume they Joe> don't, we issue a warning and then tell the compiler that Joe> there is aliasing. (A variant is to silently accept the Joe> code, but I would prefer issuing a warning). If we fall into Joe> the "maybe" case, we assume no aliasing if the types don't Joe> match. I'd thought vaguely about this alternative in the past. It is indeed technically feasible. However, I have a rather serious objection: it means that users cannot tell whether their code is valid, even according to the GCC rules, without knowing the internals of the compiler. (It's dependent on what the compiler can figure out about two addresses aliasing. If the compiler gets dumber, code breaks. The compiler shouldn't get dumber, in general, but it might in certain situations, while getting smarter in others. For example, if we replace some optimization algorithm with another, we might do better in the average case, but worse in some particular case. Things that we used to know aliased we're now not sure about. Programs break.) However, I do think this might be a good way to get useful warnings. So, I would amend your proposal to "issue a warning and then tell the compiler that there is no aliasing." This would make it easier for users to tell that there is a problem, which would indeed be a major benefit. The compiler should continue to aggressively break code that misbehaves in this way. Because we cannot (for technical reasons) guarantee behavior in the future, we should break programs now; that will make for fewer surprises down the road. Coding like this is really no different than, say, assuming that you call a varargs function without a prototype in sight. It used to work on most systems, and it still works on some. But, it's not portable, and people shouldn't do it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: jbuck@synopsys.COM Cc: gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990908184709F.mitchell@codesourcery.com> References: <199909090109.SAA28465@atrus.synopsys.com> X-SW-Source: 1999-09n/msg00317.html Message-ID: <19990930180200.ty8-nmQsj4lUw-FoVz8SidueidUhQu7enSulwlCRbSE@z> >>>>> "Joe" == Joe Buck writes: Joe> The change is simply to postpone the type-based check until Joe> after the other analysis is done. If we detect that the Joe> references collide, but the types say that we can assume they Joe> don't, we issue a warning and then tell the compiler that Joe> there is aliasing. (A variant is to silently accept the Joe> code, but I would prefer issuing a warning). If we fall into Joe> the "maybe" case, we assume no aliasing if the types don't Joe> match. I'd thought vaguely about this alternative in the past. It is indeed technically feasible. However, I have a rather serious objection: it means that users cannot tell whether their code is valid, even according to the GCC rules, without knowing the internals of the compiler. (It's dependent on what the compiler can figure out about two addresses aliasing. If the compiler gets dumber, code breaks. The compiler shouldn't get dumber, in general, but it might in certain situations, while getting smarter in others. For example, if we replace some optimization algorithm with another, we might do better in the average case, but worse in some particular case. Things that we used to know aliased we're now not sure about. Programs break.) However, I do think this might be a good way to get useful warnings. So, I would amend your proposal to "issue a warning and then tell the compiler that there is no aliasing." This would make it easier for users to tell that there is a problem, which would indeed be a major benefit. The compiler should continue to aggressively break code that misbehaves in this way. Because we cannot (for technical reasons) guarantee behavior in the future, we should break programs now; that will make for fewer surprises down the road. Coding like this is really no different than, say, assuming that you call a varargs function without a prototype in sight. It used to work on most systems, and it still works on some. But, it's not portable, and people shouldn't do it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com