This is the mail archive of the
mailing list for the GCC project.
Re: Finding Aliasing Bugs
- To: gcc at gcc dot gnu dot org
- Subject: Re: Finding Aliasing Bugs
- From: "Zack Weinberg" <zackw at stanford dot edu>
- Date: Wed, 30 May 2001 19:54:54 -0700
On Wed, May 30, 2001 at 02:47:47PM -0700, Bruce Korb wrote:
> dewar wrote:
> > No one is saying they are easy to find, but that's not a good argument for
> > having the compiler operate in crippled mode by default. Remember we are
> > only arguing about the default setting here.
> Which is an inconvenience for people not prepared to deal with the
> It seems like it ought to be possible to warn about where and when
> presumed non-aliasing is being used for optimizing purposes. With such
> a warning and observed differences between optimized and non-optimized
> code, it would at least be possible for people to focus their efforts
> on understanding those optimized parts of the code.
Please, everyone, go read the previous debates on this topic in the
archives before we rehash the entire thing. I believe they took place
in the first quarter of 2000.
At that time I looked briefly into providing warnings when aliasing
clashes could happen. My conclusion was that any simple warning would
get far too many false positives *and* false negatives to be of use,
and that a more careful warning was beyond my abilities. I imagine
that someone more familiar with RTL and alias.c could implement a
reasonably good warning in a week or two. You'd need alias.c to keep
track of "these two pointers are known to alias" as well as "these two
pointers are known *not* to alias" and "language says these pointers
may be assumed not to alias". Then you could issue a warning whenever
a pair of pointers was in both categories 1 and 3. Implementing
category 1 was what was beyond my abilities. Note that category 1
would be useful for more than just warnings; in Fortran, for instance,
aliasing is assumed not to exist unless set up by EQUIVALENCE.
Unfortunately, even a warning like that would not catch the tricky
cases where the aliasing is set up in one translation unit, but the
code that breaks is in a different one.
zw The MacsBug debugger symbol displayed as the pc location for the memory
manager's code has been changed from BowelsOfTheMemoryMgr to the more
descriptive name YourHeapIsProbablyCorrupt.
-- Apple Tech Note 2010