[llvm-bugs] [Bug 35503] Bug in union member handling in TBAA

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35503

Ivan Kosarev <ikosarev at accesssoftek.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #7 from Ivan Kosarev <ikosarev at accesssoftek.com> ---
(In reply to Hal Finkel from comment #6)
> (In reply to Ivan Kosarev from comment #4)
> > The failure is caused by this snippet:
> > 
> > ---
> >   short *q;
> >   p->u.vec[i] = 0;
> >   q = &p->u.vec[16];
> >   *q = 1;
> >   return p->u.vec[i];
> > ---
> > 
> > LLVM currently implements a TBAA model that assumes that differently-typed
> > accesses may never alias. For this reason we require accesses to union
> > members to have their most enclosed union objects specified explicitly and
> > taking addresses of union members is thus not allowed in strict-aliasing
> > mode.
> 
> No, I don't believe that's a model we do, or can, implement. What we have
> agreed is that type-changing accesses must be explicitly through the
> containing union. This, however, does not prohibit taking points to union
> members. It simply means that access through such pointers can't be
> type-changing accesses.

Ah, I see. So the idea is that type-changing accesses work as barriers, and
between that barriers types of pointers match the types of objects they point
to. I think we can implement this. Will prepare another patch. Thanks a lot for
the clarifications!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171205/861674a3/attachment.html>