[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