gcc3 vs 176.gcc

[Joe Buck]

I wrote:	
> >There's a fairly easy approach that some might consider overly aggressive
> >in that there will be some false positives: issue a warning when
> >a pointer type is cast to an incompatible (for purposes of the aliasing
> >rules) pointer type, (e.g. cast from int* to float*).

Linus writes:
> As somebody who has a project that casts pointers a lot, I would
> absolutely _love_ to see this.
> 
> Fairly clearly casting to/from a "void *" should not ever warn

Right, casts from/to any type and a void* or a char* (plus or minus
any const or volatile keywords) would not trigger the warning as they
have no aliasing implications.  Likewise, casts that add or remove
a "signed" or "unsigned" attribute don't trigger the warning (e.g.
unsigned char* <-> char*, unsigned short* <-> short*).

> But I'd love to see a warning if some cast even just changes the sign of
> the pointer, or a cast from (int *) -> (long *) even if the two are
> identical on that particular architecture.

The way the rules are written, casts that only change sign don't trigger
the aliasing restrictions, but casts from int to long or vice versa
do, even if int and long are the same size on that architecture.  That
is, using (int*) cast of long* pointer may cause the optimizer to wreck
your code unless -fno-strict-aliasing is given, while casting (int*)
to (unsigned int*) must not (or it's a compiler bug).

> >A more conservative approach might just flag the tree node corresponding
> >to the cast, indicating that dereferencing the pointer is problematic;
> 
> The _really_ conservative approach is to make all "nonstandard" casts do
> the same thing as the unrelated int/ptr cast was discussed to be doing:
> drop the type information as far as alias analysis is concerned, so that
> any strange casts would end up being in a lias set 0 (no warnings, no
> nothing, just generate less aggressive code).

Not issuing a warning for code that has been detected to violate ISO C
rules is not "conservative" in my book.  GCC is your only compiler, so
making GCC do what the programmer obviously intended may be feasible,  but
my code has to work on many compilers.  Making GCC do the right thing
with code that breaks the rules is one thing (I'm sympathetic), but the
user should still be warned.

I do agree with you that it would be nice to do what you describe.
However, the code to detect the problem in the front end is in many ways
independent from the backend mods needed to use the detected information,
so we can still make progress.

> That wouldn't even warn for the gcc spec test, it would just silently
> generate code that works the way the programmer intended.. 
> 
> Because, let's face it, "DWIM" _is_ a good thing.

Generating code that does what the programmer intended is a good thing.
Not telling the programmer that s/he messed up is *not* a good thing,
because further maintainance of the program might prevent GCC from "DWIM"
successfully.  As mentioned, on the RTL code on i386 we can tell by
looking at the RTL that there is aliasing even though the language says
there can't be, but evidently on the ia64 architecture we won't be
able to tell, because the structure comes out differently.

In any case, like you with the kernel, the GCC maintainers can and will
say to the people who want this feature (modify the alias set information
if certain types of bad-but-obvious code is detected) implement the
feature and send the patch in if they really want it.