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@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 >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
