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

Nathan Sidwell via cfe-commits cfe-commits at lists.llvm.org
Fri Dec 15 11:22:49 PST 2023


urnathan wrote:

> > > FWIW the GCC doc is https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing_003dn It says for Level 3 "If optimization is enabled, it also runs in the back end, where it deals with multiple statement cases using flow-sensitive points-to information."
> > > Do you know how it works? Any example?
> > 
> > 
> > I do not now how it works -- didn't go poking there. Neither do I have examples.
> 
> My understanding (which could be totally wrong) is that the logic for when to emit the level 3 diagnostics rests mostly in the optimizer passes. This is not something I think Clang should emulate as it creates a very poor user experience in practice (not just with strict aliasing diagnostics -- I don't think _any_ diagnostics other than remarks should be emitted based on LLVM optimization decisions aside from the `error` and `warning` attributes which are special circumstances).

I don't know if it's 'mostly', the level 3 can certainly be triggered in the FE -- it requires (a) an address-of-object idiom, (b) a suspicious cast and (c) a dereference.  Something like `*reinterpret_cast<int *>(&obj) = 5`, where `obj` is  not compatible with `int`. That's what this patch implements. (In GCC's case when it warns about this in the FE it marks the tree as warned, to inhibit the middle end also doing so.)



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


More information about the cfe-commits mailing list