[PATCH] Fix for bug 21725: wrong results with union and strict-aliasing
hfinkel at anl.gov
Tue Mar 17 17:04:35 PDT 2015
----- Original Message -----
> From: "Daniel Berlin" <dberlin at dberlin.org>
> To: "Jeroen Dobbelaere" <jeroen.dobbelaere at gmail.com>
> Cc: reviews+D8056+public+7b63cedb34d51bb1 at reviews.llvm.org, "Hal
> Finkel" <hfinkel at anl.gov>, cfe-commits at cs.uiuc.edu,
> "cfe-dev at cs.uiuc.edu Developers" <cfe-dev at cs.uiuc.edu>
> Sent: Tuesday, March 17, 2015 5:59:18 PM
> Subject: Re: [PATCH] Fix for bug 21725: wrong results with union and
> On Tue, Mar 17, 2015 at 3:41 PM, Jeroen Dobbelaere <
> jeroen.dobbelaere at gmail.com > wrote:
> > On Tue, Mar 17, 2015 at 10:24 PM, Daniel Berlin <
> > dberlin at dberlin.org
> > > wrote:
> > > [..]
> > > Note that In !41, we loose the information about the 'short'
> > > member.
> > > I would start here :)
> > > You should make it produce info about all the members.
> > Sounds reasonable.
> > > > [..]
> > >
> > > > One issue with getting array accesses right that I see, is that
> > > > the
> > > > 'offset' field can suddenly be variable.
> > >
> > > Not really. You can't say where it points, so the range would be
> > > "everything" anyway.
> > > You should just say it accesses the entire array (but not
> > > anything
> > > else).
> > In order to provide as detailed and accurate feedback as possible,
> > my
> > current changes to the tbaa analysis
> > take the (location) access size into account. This is because the
> > tbaa path information itself does not
> > contain direct size information, only offsets.
> > Is there today already a way how such variable array access can be
> > described ?
> You can't do this sanely without a lot of work, because it can
> overlap multiple actual variables and structs.
> The way we did this in GCC was to just dynamically evaluate which
> parts of which structures it could access, and then combine all
> those types.
> > Is there a way to describe that we have an array of a certain
> > type/size in the tbaa struct ?
> you can certainly describe it, but it would require metadata
> structure changes.
FWIW, I'm not opposed to such changes. We might, however, want to design them in such a way that the explicit size information can be omitted when it can be inferred from the offsets (to reduce the size of the metadata in the common case).
> > Just looking at containment of types gives some information and
> > will
> > in certain cases fix incorrect behavior, but it will also result in
> > performance degradation (due to more 'MayAliases') if offsets can
> > not be taken into account in the way they are used today.
> > Greetings,
> > Jeroen Dobbelaere
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits