r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.
George Burgess IV via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 19 21:21:33 PDT 2016
WFM; I'll put together a patch that only allows this under
I'm entirely unfamiliar with struct-path-tbaa, so Hal, do you see a reason
why struct-path-tbaa wouldn't play nicely with flexible arrays at the end
of types? Glancing at it, I don't think it should cause problems, but a
more authoritative answer would really be appreciated. :) If it might cause
issues now or in the future, I'm happy to be conservative here if
-fno-strict-path-tbaa is given, too.
On Tue, Sep 13, 2016 at 2:00 PM, Joerg Sonnenberger via cfe-commits <
cfe-commits at lists.llvm.org> wrote:
> On Tue, Sep 13, 2016 at 12:51:52PM -0700, Richard Smith wrote:
> > On Tue, Sep 13, 2016 at 10:44 AM, Joerg Sonnenberger via cfe-commits <
> > cfe-commits at lists.llvm.org> wrote:
> > > IMO this should be restricted to code that explicitly disables C/C++
> > > aliasing rules.
> > Do you mean -fno-strict-aliasing or -fno-struct-path-tbaa or something
> > here? (I think we're not doing anyone any favours by making
> > say that a pattern is OK in cases when LLVM will in fact optimize on the
> > assumption that it's UB, but I don't recall how aggressive
> > -fstruct-path-tbaa is for trailing array members.)
> The former immediately, the latter potentially as well. I can't think of
> many use cases for this kind of idiom that don't involve type prunning
> and socket code is notoriously bad in that regard by necessity.
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits