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

Eli Friedman via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 15 12:46:35 PST 2023


efriedma-quic 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?)

On the LLVM side, there's very little interesting logic; it's basically just walking the tree of metadata nodes generated by clang.  See https://llvm.org/docs/LangRef.html#tbaa-node-semantics .  The hard part of the refactoring would just be adding an abstraction for the underlying information.

gcc has made various unfortunate decisions regarding diagnostics in the past; we've put a lot of effort into making sure our diagnostics are more consistent.

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


More information about the cfe-commits mailing list