gcc3 vs 176.gcc

[Linus Torvalds]

In article <200201101852.KAA18027@atrus.synopsys.com> you write:
>I wrote:
>> > There are two ways of detecting it: based on offsets against registers
>> > (which would exist only in some back ends), or based on types of pointers
>> > closer to the source.  The latter type of check would work on all targets.
>
>geoffk writes:
>> This sounds promising.  Would anyone like to propose a patch?
>
>First we need to settle on what we will warn about.
>
>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*).

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, as that
would just be too noisy for obviously legal code.  That also gives you a
way to avoid the warning if you really really know what you're doing,
and want to do

	float * fp.
	int *p = (int *)(void *)fp;

without getting the warning.

Similarly, a "char *" is special in traditional C (and can be commonly
used even in modern C by programs that want to do pointer arithmetic on
bytes - gcc has the "void *" arithmetic extension, but that's a
gcc'ism), and is also special for aliasing purposes, so it probably
shouldn't warn by default (possibly with a way to enable it). 

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.

At least I _think_ I would love such a warning. It's hard to tell just
how noisy it would be, and maybe there are valid cases for it (although
I can't think of many).

>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).

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.

		Linus