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: <199909090502.WAA24772@atrus.synopsys.com> References: <19990908214911I.mitchell@codesourcery.com> X-SW-Source: 1999-09n/msg00334.html Message-ID: <19990930180200.Ubg7zY8YUqrscHo45cfmtiowQe-XMCUkE5kbpwAvH1A@z> > One of your assumptions is that the only times we ask `does x alias y' > are when it is sensible to do so. :-) We likely do so at other times > as well; I didn't point this out, but should have. Consider: > > void *v = malloc (4); > if (p) > * ((float *) v) = 3; > else > * ((int *) v) = 7; > > This code is conforming. I don't mind terribly if we warn on this > code; I bet the number of false positives will be small. But, we > shouldn't force the compiler to go slower in this case. I guess I am missing something in this example. Could you explain why we would get a warning? The accesses are legal. Yes, if you check whether the two assignments alias there would be the possibility of a false warning if you aren't careful. > You asked users with nonconformant code whether local analysis would > spot the bugs. In some cases it will. In others, it won't. In some, > it will depend on what the compiler does. For example, does it inline > some function? If so, more things become local. So, now you have > programs that might work with -O3 but might break with -O2. But this is just the reverse of what happens now; since -O2 will do more reordering than -O, we already have programs that work with -O and don't work with -O2 because of type-based aliasing. > Saying "Don't violate ANSI/ISO aliasing rules, or else use > -fno-strict-aliasing" is a simple, easy-to-follow rule. I don't think > we should muddy that with confusing semantics depending on GCC > internals. I don't disagree. You see, my code is silent in the presence of -Wall, so in that sense the choice of A vs B would be a no-op for me; either way, I would find and fix the aliasing bug. If we issue a warning, and the users never bother to clean up the warning, it is the user's loss when the code later breaks. So, if I can only have your amended proposal, I suppose I'll take it. It's better than nothing.