From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: law@cygnus.com Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 09 Sep 1999 07:58:00 -0000 Message-id: <19990909145321.4127.qmail@deer> References: <3172.936868662@upchuck.cygnus.com> X-SW-Source: 1999-09/msg00355.html > In message < 19990908202957F.mitchell@codesourcery.com >you write: > > 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. Warning here is sensible, though, > > just as warning on `*((int*) 0) = 3' in the conditional code would be > > sensible. >FYI, this kind of code could be deleted at a variety of stages in compilation >depending on what optimization exposed the unreachable code (terminology >note, this is unreachable code, not dead code ;-) [...] IMO, when you are considering stuff like this, please replace if (0) with scanf ("%d", &i); /* or whatever, i hate scanf anyway, think READ *, I. */ if (i) and the programmer's "out-of-band" promise that anytime that that particular scanf executes, it will always read a 0 (from stdin). I'm not *sure* about this, but it looks like this discussion is going in the direction of "we can do something not quite kosher by finding all cases of suspect code that won't actually be reached in practice". If that's the case, it's wrong. BTW, I agree 100% with this contribution from Mark: >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 also agree a warning where we *can* detect potential aliasing violations would be nice. Leave it to the usual "discovery process" to determine whether it should be the default, the default for -Wall, whatever. However, it's my impression that the mere printing, even requesting, of a warning should make *no* difference in the generated code. Just like gcc promises for -g, except, here, I mean no difference in the generated assembler output, not just the code within that. In that case, it would be wrong to connect to the printing of a warning (or the user requesting that type of warning) doing something like turning off alias analysis. GCC doesn't, upon warning about a possible uninitialized variable, silently insert an initialization, does it? (By which I mean, we don't document that it does that, right?) Note that falling back to the "let's just generate a warning" position isn't a panacea: #!/bin/sh, or some approximation thereof # Compile $1 vis-a-vis gcc's annoying aliasing behavior and options in $2. gcc -Walias $2 -c $1 2>diagnostics.out status=$? if [ $status != 0 ] then exit $status fi # See if any alias warnings were issued, and recompile without alias # analysis if so. grep -q alias diagnostics.out if [ $? = 0 ] then gcc -fno-alias-analysis $2 -c $1 status = $? fi rm diagnostics.out exit $status People who think GCC should have done what has been recommended here, i.e. revert to no alias analysis upon detecting possible violations (and warning about them), will probably use a script like the above to get the desired behavior themselves. And, they will complain just as loudly when it "stops working", which will mean, to them, either "no longer catches a particular aliasing violation in my code, leading to hours of my time tracking down this GCC bug causing a failure to correctly warn" or "now warns about something that isn't really a problem, leading to hours of my time tracking down this loss of performance". (I'm not saying this sort of end-user behavior is to be expected for all instances of generating warnings about not-strictly-correct code. But given the huge amount of attention this problem, which has long had the simple -fno-strict-aliasing workaround, has gotten on this list during just this year, I think *this* particular warning is a candidate for this sort of treatment.) tq vm, (burley) From mboxrd@z Thu Jan 1 00:00:00 1970 From: craig@jcb-sc.com To: law@cygnus.com Cc: craig@jcb-sc.com Subject: Re: type based aliasing again Date: Thu, 30 Sep 1999 18:02:00 -0000 Message-ID: <19990909145321.4127.qmail@deer> References: <3172.936868662@upchuck.cygnus.com> X-SW-Source: 1999-09n/msg00355.html Message-ID: <19990930180200.R_6AppyWuzE8d3-rJdtLSDEPd5S1kAhh5FOooDoKE7g@z> > In message < 19990908202957F.mitchell@codesourcery.com >you write: > > 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. Warning here is sensible, though, > > just as warning on `*((int*) 0) = 3' in the conditional code would be > > sensible. >FYI, this kind of code could be deleted at a variety of stages in compilation >depending on what optimization exposed the unreachable code (terminology >note, this is unreachable code, not dead code ;-) [...] IMO, when you are considering stuff like this, please replace if (0) with scanf ("%d", &i); /* or whatever, i hate scanf anyway, think READ *, I. */ if (i) and the programmer's "out-of-band" promise that anytime that that particular scanf executes, it will always read a 0 (from stdin). I'm not *sure* about this, but it looks like this discussion is going in the direction of "we can do something not quite kosher by finding all cases of suspect code that won't actually be reached in practice". If that's the case, it's wrong. BTW, I agree 100% with this contribution from Mark: >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 also agree a warning where we *can* detect potential aliasing violations would be nice. Leave it to the usual "discovery process" to determine whether it should be the default, the default for -Wall, whatever. However, it's my impression that the mere printing, even requesting, of a warning should make *no* difference in the generated code. Just like gcc promises for -g, except, here, I mean no difference in the generated assembler output, not just the code within that. In that case, it would be wrong to connect to the printing of a warning (or the user requesting that type of warning) doing something like turning off alias analysis. GCC doesn't, upon warning about a possible uninitialized variable, silently insert an initialization, does it? (By which I mean, we don't document that it does that, right?) Note that falling back to the "let's just generate a warning" position isn't a panacea: #!/bin/sh, or some approximation thereof # Compile $1 vis-a-vis gcc's annoying aliasing behavior and options in $2. gcc -Walias $2 -c $1 2>diagnostics.out status=$? if [ $status != 0 ] then exit $status fi # See if any alias warnings were issued, and recompile without alias # analysis if so. grep -q alias diagnostics.out if [ $? = 0 ] then gcc -fno-alias-analysis $2 -c $1 status = $? fi rm diagnostics.out exit $status People who think GCC should have done what has been recommended here, i.e. revert to no alias analysis upon detecting possible violations (and warning about them), will probably use a script like the above to get the desired behavior themselves. And, they will complain just as loudly when it "stops working", which will mean, to them, either "no longer catches a particular aliasing violation in my code, leading to hours of my time tracking down this GCC bug causing a failure to correctly warn" or "now warns about something that isn't really a problem, leading to hours of my time tracking down this loss of performance". (I'm not saying this sort of end-user behavior is to be expected for all instances of generating warnings about not-strictly-correct code. But given the huge amount of attention this problem, which has long had the simple -fno-strict-aliasing workaround, has gotten on this list during just this year, I think *this* particular warning is a candidate for this sort of treatment.) tq vm, (burley)