jyknight added a comment. In https://reviews.llvm.org/D47894#1125961, @srhines wrote:
> In https://reviews.llvm.org/D47894#1125728, @jyknight wrote: > > > In https://reviews.llvm.org/D47894#1125653, @efriedma wrote: > > > > > The problem would come from propagating nonnull-ness from something which > > > isn't inherently nonnull. For example, strlen has a nonnull argument, so > > > `strlen(NULL)` is UB, therefore given `int z = strlen(x); if (x) {...}`, > > > we can remove the null check. (Not sure we actually do this transform at > > > the moment, but it's something we could do in the future.) > > > > > > I think the question there is actually whether we need to, in addition to > > supporting null pointer dereference, also cause all > > `__attribute__((nonnull))` annotations at the C/C++ level to be ignored. > > > > And, yes, I believe we should. > > > Is that what the kernel community actually wants though? There are certainly > others who want a way to strip `__attribute__((nonnull))` completely, which > seems a bit orthogonal to the removal of null checks in general. I think it > would be good to support such a flag, but the presence of `nonnull` inside > kernel sources leads me to believe they want those cases to be treated > specially. In GCC, the nonnull attribute still has an effect on warnings but not on codegen if you enable -fno-delete-null-pointer-checks: https://godbolt.org/g/7SSi2V That seems a pretty sensible behavior, IMO. Repository: rC Clang https://reviews.llvm.org/D47894 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
