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 <
> 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 <
> > firstname.lastname@example.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 mailing list