This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objects_must_conflict_p


    > I think you're right.  It would be enough to check if the alias sets have
    > a common subset.

    Are you sure this would be sufficient? Both aggregates can have an 'int' 
    field and this won't prevent problems between 'int' and 'double' fields.

Actually, now I'm confused.  I've always found this "must conflict" stuff
confusing since it's backwards from the way we normally think about it.
So try again to explain what it's doing wrong, since my comment makes no
sense when I go back and look at it.

    Btw, why did you choose to always return 0 for scalar vs aggregate? In
    this case, I think that alias_sets_conflict_p is the right criterion.

Good question.  I should have put it in the comment and didn't, which was
not good.  And I don't remember.  Sorry.  One approach is to take it out
and see what breaks.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]