This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: type based aliasing again


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]