[clang] [clang] Strict aliasing warning ala GCC [PR50066] (PR #74155)

Nathan Sidwell via cfe-commits cfe-commits at lists.llvm.org
Wed Dec 6 04:26:11 PST 2023


urnathan wrote:

> Making Sema pull the TBAA info out of clang/lib/CodeGen is a layering violation (and probably breaks if we aren't actually generating code). If we need some notion of "aliasing" in Sema, we should pull the relevant code into clang/lib/AST.

That's unfortunate.  The code will not call the TBAA stuff if the code generator doesn't provide that predicate -- so if not generating optimized code the warning is inactive.  This is the same as with GCC btw. To be clear what's exposed is a new predicate allowing querying of type conversion's TBAAness -- the representations of TBAA etc are not exposed.  The CodeGen TBAA machinery builds on llvm's aliasing MDNodes. It would seem a large task to replicate that in AST (and I presume propagating llvm's bits further into AST is even worse?)

> I don't have any experience with this warning, so I'm not sure how effective it is at detecting issues; do a significant fraction of issues actually show up at a pure syntactic level? Do you have any idea what false positive rate we should expect?

I think at level 3 the false positive rate is very low. Given GCC's extended this over the years from the simple check I had (IIRC any reinterpret_cast between pointers/references to TBAA incompatible types) to the semantics it has now suggests the warning is useful. and the level 3 default is satisfactory. But I don't have hard data.

https://github.com/llvm/llvm-project/pull/74155


More information about the cfe-commits mailing list