r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks.

[George Burgess IV via cfe-commits]

WFM; I'll put together a patch that only allows this under
-fno-strict-aliasing.

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
> else
> > here? (I think we're not doing anyone any favours by making
> _FORTIFY_SOURCE
> > 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.
>
> Joerg
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160919/e5436631/attachment-0001.html>