Well, the current warning only applies to code which casts the address
of an object. That is, when I said "(T*)&x" I really meant it. So,
no, gcc is not going to give a warning for code like your example.

> Also, can you give me examples of cases when GCC generates false> warnings and when it doesn't catch "proper" ANSI rules violations?

gcc currently generates a false warning for:

int i;
void foo () { short *p = (short *)&i; *(int *)p = 1; }

gcc currently does not generate a warning fo:

int i;
void foo () { short *p = (short *)(void *)&i; *p = 1; }

> Is it due to internal GCC issues (like losing some type information> in IR) or due to perplexities of ANSI rules?

It's because the current warning implementation is very simple-minded.

> And the last question: are your colleague based his implementation on> an openly available paper, or devised everything himself?

He devised everything himself, based on the existing alias analysis
code in gcc. That is, he does not attempt to warn about any possible
aliasing violation; he only warns about those aliasing violations
which gcc is able to exploit.