[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Everyone working on the C side might want to read this article...

From: Bruce Korb
Subject: Re: Everyone working on the C side might want to read this article...
Date: Mon, 28 Apr 2003 14:02:36 -0700

Rob Browning wrote:
> Rob Browning <address@hidden> writes:
> > The following article explains gcc changes that may be behind at least
> > some of our recent set of bugs:
> >
> >
> So does anyone have thoughts about how we should approach this issue?
> How common do we think these type aliasing problems might be in our
> code, and if we do have problems, can we just fix each offending bit
> of code with temp assignments or other "disambiguating" statements, or
> is there some higher level way we might be able to address the issue
> (i.e. could a union help here, something else?).

The default optimization is sufficient for many of the aliasing
problems.  If you compile with the GCC 3.3 branch -Wall will trigger
some extra aliasing-related warnings.  Examine the warnings carefully.
Remember that just because it didn't warn doesn't mean there isn't
a problem.  However, the warnings do actually cover most of the common
ways aliasing breaks code.  WRT how to fix, there are several solutions:

1.  you can go the way of the kernel and -fno-strict-aliasing
2.  you can unionize the pointer types
3.  you can use the "I can point to anything" pointer types
    viz., char* and void*.

A sure fire test, once you've discovered a problem, is to
try rebuilding with -fno-strict-aliasing and see if the
problem goes away.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]