This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH: PR 25895, 25856, 25858
- From: Gabriel Dos Reis <gdr at cs dot tamu dot edu>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: richard dot guenther at gmail dot com (Richard Guenther), mark at codesourcery dot com (Mark Mitchell), gcc-patches at gcc dot gnu dot org
- Date: 22 Jan 2006 11:52:55 -0600
- Subject: Re: C++ PATCH: PR 25895, 25856, 25858
- References: <200601221742.k0MHgGer027913@earth.phy.uc.edu>
Andrew Pinski <pinskia@physics.uc.edu> writes:
| >
| >
| > | > Andrew Pinski wrote:
| > | >
| > | > > Actually the optimization is invalid as
| > | > >
| > | > > struct a
| > | > > {
| > | > > int t;
| > | > > };
| > | > >
| > | > > bool f(void)
| > | > > {
| > | > > a *b = 0;
| > | > > return &b->t == 0;
| > | > > }
| > | > >
| > | > > that should return 1 as it is a null pointer.
| >
| > If the middle-end optimizer is coherent, I don't quite understand why
| > it *should* return 1. The bug Mark fixed came from the fact that the
| > middle-end still thinks dereferencing implies b not being null. Given
| > that a::t resides at same address as the containing object, if b
| > is supposed nonnull, it follows that &b->t cannot be null.
| > And I'm sure you know your example is invalid.
|
| If you consider c-common.c middle-end.
s/middle-end/c-common.c/g if that helps.
I still no do not understand the reasoning that led you to your
statement.
-- Gaby