From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: mark@codesourcery.com (Mark Mitchell) Cc: jbuck@synopsys.com, gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Wed, 08 Sep 1999 19:25:00 -0000 Message-id: <199909090223.TAA21727@atrus.synopsys.com> References: <19990908184709F.mitchell@codesourcery.com> X-SW-Source: 1999-09/msg00320.html > 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. Mark Mitchell writes: > 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. This is only true if we say that code for which we issue the warning is valid under the GCC rules. We could just as well say that it is *invalid* and we are issuing the warning to help the user. So I don't see how doing this could cause any harm. Yes, we won't catch all cases, but we'll be educating users. They'll see the warning occasionally, ask about it, and learn. > 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. This is fine with me, in fact that is really what I am proposing. (RMS might have wanted to just accept it, but he said that a warning would be OK with him). > The compiler should continue to aggressively break code that > misbehaves in this way. This is a philosophical issue. If you change "break" to "warn about" I could go along, but some users may be depending on code that they cannot fix immediately. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: mark@codesourcery.com (Mark Mitchell) Cc: jbuck@synopsys.com, gcc@gcc.gnu.org, rms@gnu.org Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <199909090223.TAA21727@atrus.synopsys.com> References: <19990908184709F.mitchell@codesourcery.com> X-SW-Source: 1999-09n/msg00320.html Message-ID: <19990930180200.k4kDCiGYckohl-mYBT9Ljd43CDLaVlzzT_8tmXS4SQI@z> > 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. Mark Mitchell writes: > 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. This is only true if we say that code for which we issue the warning is valid under the GCC rules. We could just as well say that it is *invalid* and we are issuing the warning to help the user. So I don't see how doing this could cause any harm. Yes, we won't catch all cases, but we'll be educating users. They'll see the warning occasionally, ask about it, and learn. > 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. This is fine with me, in fact that is really what I am proposing. (RMS might have wanted to just accept it, but he said that a warning would be OK with him). > The compiler should continue to aggressively break code that > misbehaves in this way. This is a philosophical issue. If you change "break" to "warn about" I could go along, but some users may be depending on code that they cannot fix immediately.