[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:
> >
> > http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm
>
> 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.