Re: type based aliasing again

[John Vickers <jvickers at dial dot pipex dot com>]

Joe Buck wrote:
> 
> Jeff writes:
> 
> > In general, we are going to be doing alias checks across basic blocks in
> > support of global optimizations.  So we can't assume that just because
> > two memory reerences are in different blocks that we will not ask about the
> > aliasing relationship between them.
> 
> This, and Mark's examples, make clear that just because we see two
> references to the same address that are of different (non-char *)
> types, we can't conclude automatically that the user has violated
> the rules.  We'd have to know somehow that one of the references
> represents the true dynamic type and the other represents some other
> type.  This makes things a little trickier.
> 
> I think we're going to need to try out some patches so that we can
> do some experimentation.  How many false triggers would we get if
> we followed my original naive approach (perhaps using Mark's
> alterative B modification: issue the warning but proceed using
> the ANSI rules)?
> 

> I don't think it's appropriate for us to throw up our hands and say
> the problem is too hard.  

> There's a lot of code out there that breaks
> the rules, and users will need at least some help finding it.
> Otherwise people will just start putting -fno-strict-aliasing
> in all their Makefiles, and Mark's work will not benefit users.

This is the real problem.

A lot of the code - proprietary or otherwise - which people expect to
just "work" with gcc has no active maintainer.  Maybe it has no
maintainer
precisely because this same code has been working fine for years.

Linus has confused matters.  Linux is actively maintained.  Linus should
put up
or shut up.  If the folks who write linux & approve linux patches don't
understand
ANSI C that's their problem.  It's not as if ANSI/ISO C was something
new.
But the fuss he has made has diverted attention from the fact that a
vastly larger
body of semi-maintained software is now liable to break.

On the warning side, in practice it seems that many offending constructs
involve creating a single local variable, taking it's address, and
casting that address
to a different pointer type.  If even just that usage, within a single
basic block, were
diagnosed,  maybe a useful proportion of the problem cases would be
caught.

Regards,

John.