This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++ and aliasing bools
- From: Daniel Berlin <dan at dberlin dot org>
- To: Joe Buck <jbuck at synopsys dot com>
- Cc: Dan Nicolaescu <dann at godzilla dot ics dot uci dot edu>, Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 25 Jan 2002 21:37:33 -0500 (EST)
- Subject: Re: g++ and aliasing bools
On Fri, 25 Jan 2002, Joe Buck wrote:
>
> > I bootstrapped this version on sparc-sun-solaris2.8:
> >
> > {
> > if (AGGREGATE_TYPE_P (t) &&
> > !((TREE_CODE (t) == RECORD_TYPE)
> > && !CLASSTYPE_NON_POD_P(t)
> > && !CLASSTYPE_N_BASECLASSES(t)))
> > return 0;
> > }
>
> CLASSNAME_NON_POD_P returns false if there are any methods or if there
> is a constructor or destructor, right? If so, then I think we're going
> to get little gain: much of the payoff from better aliasing in C++ will
> come if we don't get false aliasing complaints for things like STL
> iterators. At least in my code, I don't have many NON_PODs; even if
> it's a plain struct otherwise, I use a constructor to initialize it.
Constructors and destructors should be fine, well, sorry, *non-virtual*
destructors should be fine.
Unless adding non-virtual destructors and constructors affect object
layout in memory somehow.
>
> On the other hand, some of the STL iterators are derived classes. Sigh.
>
One thing at a time, of course.