----- Original Message ----- > From: "George Burgess IV" <george.burgess...@gmail.com> > To: "Hal Finkel" <hfin...@anl.gov> > Cc: "Richard Smith" <rich...@metafoo.co.uk>, "Joerg Sonnenberger" > <jo...@bec.de>, "cfe-commits" > <cfe-commits@lists.llvm.org> > Sent: Monday, September 19, 2016 11:21:33 PM > Subject: Re: r281277 - [Sema] Fix PR30346: relax __builtin_object_size checks. > > > 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.
We currently don't emit struct-path-tbaa for array members. We likely should, and we'll need to keep flexible array members in mind when we implement that extension. I don't think that the current representation has a way to represent an unbounded size (except for using ((size_t) -1), which might be as good as anything else). -Hal > > On Tue, Sep 13, 2016 at 2:00 PM, Joerg Sonnenberger via cfe-commits < > cfe-commits@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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > > -- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
