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 21:56:00 -0000 Message-id: <19990908220054J.mitchell@codesourcery.com> References: <19990908202957F.mitchell@codesourcery.com> <199909090430.VAA24607@atrus.synopsys.com> X-SW-Source: 1999-09/msg00333.html >>>>> "Joe" == Joe Buck writes: >> I agree that C is reasonable. But, it is not technically >> viable at compile-time; the violation of the rule is a dynamic >> property. For example, consider: >> >> if (0) { /* Do illegal aliasing stuff. */ } >> >> If we do dead-code elimination late, we might ask questions >> about the aliasing in the conditional code. Since that code >> never executes, ANSI says there's no violation. Joe> Careful. Are you sure that ANSI says that we can't call this Joe> an error? Here's a little language from [intro.execution] in the C++ standard. (It's the same, in spirit, as the C standard.) However, if any such execution sequence contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation). There's no execution sequence that causes the illegal behvaior. (Your example, with const, is ill-formed, which is different.) Someone might care to argume otherwise, though; the standard isn't crystal clear in this respect. But, that still leaves the problem mentioned in my other email; giving an error here would require that we only ask whether two things alias when that's sensible; the if (x) *((short *) v) = 3; else *((int *) v) = 7; example would then be one in which we *must* not ask whether these two things alias. That's an unreasonable technical restriction on the compiler. -- 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: <19990908220054J.mitchell@codesourcery.com> References: <19990908202957F.mitchell@codesourcery.com> <199909090430.VAA24607@atrus.synopsys.com> X-SW-Source: 1999-09n/msg00333.html Message-ID: <19990930180200.Ti1v4dD1245hYw0cH8vXxHixJSnU9_TMqsmjsc_5NLI@z> >>>>> "Joe" == Joe Buck writes: >> I agree that C is reasonable. But, it is not technically >> viable at compile-time; the violation of the rule is a dynamic >> property. For example, consider: >> >> if (0) { /* Do illegal aliasing stuff. */ } >> >> If we do dead-code elimination late, we might ask questions >> about the aliasing in the conditional code. Since that code >> never executes, ANSI says there's no violation. Joe> Careful. Are you sure that ANSI says that we can't call this Joe> an error? Here's a little language from [intro.execution] in the C++ standard. (It's the same, in spirit, as the C standard.) However, if any such execution sequence contains an undefined operation, this International Standard places no requirement on the implementation executing that program with that input (not even with regard to operations preceding the first undefined operation). There's no execution sequence that causes the illegal behvaior. (Your example, with const, is ill-formed, which is different.) Someone might care to argume otherwise, though; the standard isn't crystal clear in this respect. But, that still leaves the problem mentioned in my other email; giving an error here would require that we only ask whether two things alias when that's sensible; the if (x) *((short *) v) = 3; else *((int *) v) = 7; example would then be one in which we *must* not ask whether these two things alias. That's an unreasonable technical restriction on the compiler. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com