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: Finding Aliasing Bugs


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


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